SNHP — free negotiation math + agent memory
Server Details
Free game-theory negotiation advisor for agents, plus paid receipted sessions and agent memory.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ryuxik/snhp
- GitHub Stars
- 0
- Server Listing
- SNHP
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 15 of 15 tools scored. Lowest: 3.3/5.
Most tools have distinct purposes (e.g., auctions, negotiation, pricing, matching, memory). However, negotiate/session_advise and negotiate_bundle/session_bundle overlap in functionality, differing only in payment tier, which could cause confusion.
Tool names generally follow a verb_noun pattern in snake_case. 'negotiate' is a lone verb without a noun, but overall the convention is consistent and predictable.
15 tools cover a broad domain of negotiation, auctions, pricing, matching, and memory. While slightly on the higher side, each tool serves a clear purpose and the count is reasonable for the scope.
The tool surface covers key negotiation scenarios (single/multi-issue, free/paid, auctions, clearance pricing, stable matching) and adds memory persistence. Minor gap: no explicit tool for managing user preferences or profiles.
Available Tools
15 toolsauction_bidOptimal auction bidARead-onlyInspect
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 | Required | Description | Default |
|---|---|---|---|
| my_valuation | Yes | What the item is worth to YOU, in dollars. | |
| reserve_price | No | The auction's reserve/minimum bid in dollars, if any (optional). | |
| risk_aversion | No | Your risk aversion; 1.0 = risk-neutral (default 1.0). | |
| auction_format | Yes | 'first_price' (sealed), 'second_price_vickrey', or 'english_ascending'. | |
| n_competing_bidders | Yes | How many OTHER bidders there are (not counting you). | |
| competitor_value_prior | 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}}. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| rationale | No | |
| optimal_bid | No | |
| win_probability | No | |
| expected_surplus | No | |
| dominant_strategy | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds further transparency: 'free, no account or key needed' (no authentication), and clarifies that inputs like competitor_value_prior are approximations. No contradictions.
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 description is well-structured with a clear summary, usage guidance, parameter explanation, return fields, and an example. Every sentence serves a purpose; no unnecessary text.
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?
Given the tool's complexity (6 params, nested objects, output schema), the description covers purpose, usage, parameters, output, and provides an example. It is sufficiently complete for effective use.
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 coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining the competitor_value_prior with examples and emphasizing that values are in same currency. However, it omits the optional parameters risk_aversion and reserve_price, which are present in schema.
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 clearly states the tool computes the optimal bid for a bidder in an auction. It uses a specific verb ('optimal bid'), specifies the resource, and distinguishes from siblings (auction_reserve for running auctions, negotiate for haggling).
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?
Explicitly states when to use ('when you're a bidder wanting to maximize surplus') and when not to use ('NOT for running an auction' or '1:1 haggling'), with direct references to alternative tools (auction_reserve, negotiate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
auction_reserveRevenue-optimal reserve priceARead-onlyInspect
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 | Required | Description | Default |
|---|---|---|---|
| n_bidders | Yes | How many bidders you expect. | |
| seller_valuation | Yes | What the item is worth to YOU, in dollars (your floor). | |
| bidder_value_prior | Yes | Rough model of what bidders will pay, e.g. {family:'uniform', params:{low:2000, high:8000}}. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| rationale | No | |
| reserve_price | No | |
| expected_revenue | No | |
| expected_efficiency_loss | No | |
| expected_revenue_no_reserve | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the tool is 'free, no account or key needed', which adds transparency beyond the readOnlyHint annotation. It also clarifies it's a calculation tool that returns reserve price and expected revenue. No contradictions with annotations.
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 description is well-structured with clear sections (USE THIS WHEN, NOT, Provide, Example) and front-loads the purpose. It is slightly verbose with the example, but every sentence adds value. Minor conciseness penalty for length, but still effective.
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?
Given the tool has 3 parameters (including a nested object) and an output schema, the description covers everything: purpose, when to use, param explanations, estimation guidance, and a concrete example. It fully enables correct invocation without external resources.
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?
Although schema coverage is 100%, the description adds substantial meaning: it explains n_bidders as 'how many bidders', seller_valuation as 'what the item is worth to YOU', and bidder_value_prior with a detailed example format. It also provides a complete usage example, far exceeding the schema's minimal descriptions.
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 clearly states the tool computes the revenue-optimal reserve price for an auction with multiple bidders. It uses a specific verb ('compute') and resource ('reserve price'), and distinguishes itself from the sibling tool 'negotiate' by specifying it's for multi-bidder auctions, not one-on-one haggling.
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 explicitly says when to use ('when you're running an auction or sale with multiple bidders') and when not ('NOT for one-on-one haggling'), and even suggests an alternative ('use negotiate for that'). This leaves no ambiguity about appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clearance_priceClearance price & markdown scheduleARead-onlyInspect
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 = 14243600 = 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 | Required | Description | Default |
|---|---|---|---|
| seed | No | RNG seed for reproducibility (default 42). | |
| inventory | Yes | Number of units you must sell before the cutoff. | |
| n_simulations | No | Monte-Carlo sample count for the estimate (default 2000). | |
| horizon_seconds | Yes | Selling window in SECONDS (14 days = 14*24*3600 = 1209600). | |
| buyer_arrival_prior | Yes | Rough model of buyer willingness-to-pay, e.g. {family:'uniform', params:{low:40, high:150}}. | |
| arrival_rate_per_second | Yes | Expected shoppers per SECOND (= expected total shoppers / horizon_seconds). |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| rationale | No | |
| static_price | No | |
| dynamic_schedule | No | |
| sellthrough_rate | No | |
| dynamic_value_estimate | No | |
| static_expected_revenue | No | |
| static_simulated_revenue | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false. The description adds that the tool is 'free, no account or key needed' and explains the output structure (static_price, dynamic_schedule, etc.). No contradictions. It adds behavioral context beyond annotations.
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 description is well-structured with a purpose line, usage section, parameter guide, and example. It is front-loaded with key info. Slightly lengthy but each part earns its place; minor redundancy in the example block.
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?
Given 6 parameters, 4 required, 100% schema coverage, and an output schema, the description fully explains tool purpose, when to use, parameters with examples, and return values. The example call makes it immediately actionable.
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 coverage is 100%, but the description adds substantial meaning: explains horizon_seconds conversion via example, buyer_arrival_prior structure ('family', 'params'), and provides a full example call. This goes well beyond the schema descriptions.
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 states the tool generates a 'Best price plus markdown schedule to clear stock by a deadline'. It explicitly distinguishes from siblings by stating 'NOT for 1:1 haggling (negotiate) or auctions (auction_bid/reserve).' The verb 'clear' and resource 'price & schedule' are specific.
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 provides a dedicated 'USE THIS WHEN:' section: 'you must sell a FIXED number of units before a cutoff and demand arrives over time'. It also gives explicit exclusions: 'NOT for 1:1 haggling (negotiate) or auctions (auction_bid/reserve).' This clearly separates it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_loadLoad agent memoryARead-onlyInspect
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 | Required | Description | Default |
|---|---|---|---|
| ticket | Yes | The claim ticket returned by memory_save. | |
| api_key | Yes | The same SNHP API key you saved under (a different owner reads as a missing ticket). |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| code | No | |
| error | No | |
| reason | No | |
| charged | No | |
| blob_b64 | No | |
| expires_at | No | |
| size_bytes | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description goes beyond by explaining that retrieval is free, the returned blob is encrypted and only the owner can decrypt, and details possible errors (expired, at-rest key unavailable). This adds significant behavioral context not captured by annotations alone. No contradictions with annotations.
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 description is concise but includes a structured output format. It is front-loaded with the main purpose and then details. Slightly dense but still efficient.
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?
Given the presence of an output schema, the description explains the return values and error conditions comprehensively. It covers retrieval cost, encryption, ownership, and error states, making it complete for a retrieval tool with rich annotations.
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 coverage is 100% with descriptions for both parameters. The description adds value by explaining that ticket is from memory_save and that api_key must match the one used for saving. It also provides context about owner verification, which enhances the schema descriptions.
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 clearly states the action ('Load a memory'), the resource ('memory from earlier session'), and provides a specific verb ('load'). It differentiates from siblings like memory_save by mentioning retrieval of previously saved data. The return format is also specified, making the purpose unmistakable.
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 explicitly states when to use this tool ('when you saved a memory in an earlier session') and notes that retrieval is free, implying cost considerations. It doesn't explicitly say when not to use but the context with sibling memory_save makes it clear. The description also covers error states, providing good guidance on expected outcomes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_saveSave agent memory (blind locker)AInspect
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 | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your SNHP API key (a new key's 50c starter credit covers first saves). | |
| blob_b64 | Yes | YOUR ciphertext as base64 — encrypt BEFORE saving; the store holds only the sealed box and cannot read it. | |
| ttl_seconds | No | How long to keep it, clamped to [60s, 7 days]; the effective expiry is returned (optional). |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| code | No | |
| error | No | |
| reason | No | |
| ticket | No | |
| charged | No | |
| receipt | No | |
| expires_at | No | |
| size_bytes | No | |
| ticket_hash | No | |
| price_millicents | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses encryption before saving, blind custody, receipt, charging details, and ttl clamping. Annotations (readOnlyHint false, destructiveHint false) are consistent; no contradiction.
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?
Front-loaded with main purpose, but somewhat lengthy with many technical details. Still efficient; every sentence adds value.
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?
Covers security, charging, parameter constraints, and return of effective expiry. Output schema exists so return values not needed. Mostly complete for a storage tool.
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 coverage is 100%; description adds context: api_key is from SNHP with starter credit, blob_b64 is ciphertext, ttl_seconds clamped. Provides meaning beyond schema.
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 clearly states it saves persistent memory for the agent across sessions, using specific verbs and resources. It distinguishes from sibling tool memory_load (loading is free).
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?
Explains when to use (to persist memory), mentions prepaid wallet and starter credit, and that empty/oversize goes uncharged. Lacks explicit 'when not to use' but context from siblings clarifies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
negotiateNegotiate — your optimal next moveARead-onlyInspect
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 ANY counterparty with zero setup. (The verified-peer cooperation premium is the separate, advanced gt_a2a_* flow on the pro door.)
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | Short label for what's being negotiated (used only in the drafted message). | this |
| side | Yes | Which side you are: 'sell' or 'buy'. | |
| target | Yes | Your aspiration price in dollars (seller: high; buyer: low). | |
| walk_away | Yes | Your reservation price in dollars — the worst you'd accept (seller: your floor/minimum; buyer: your ceiling/maximum). | |
| compute_ms | No | EXPERIMENTAL. Milliseconds of Monte-Carlo rollouts to spend refining the move; 0 = instant closed form (validated to show no realized edge, off by default). | |
| rounds_left | No | Roughly how many back-and-forth rounds remain before the deadline (default 8). | |
| my_previous_offers | No | Your own offers so far, in dollars, oldest first (optional context). | |
| counterparty_offers | No | The other side's offers so far, in dollars, oldest first. Omit if they haven't offered yet. |
Output Schema
| Name | Required | Description |
|---|---|---|
| fit | No | |
| error | No | |
| action | No | |
| compute | No | |
| message | No | |
| rationale | No | |
| confidence | No | |
| recommended_price | No | |
| expected_settlement | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, which is consistent with a recommendation tool. Description adds behavioral context: free, no account needed, validation stats, and experimental compute_ms parameter with no realized edge. Does not contradict annotations.
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?
Well-structured with sections (when to use, parameters, return format, worked example). While lengthy, every sentence adds value. Front-loads key information (purpose, usage) and uses bullet points for clarity.
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?
Given 8 parameters, 3 required, and an output schema, the description fully covers: input semantics, return format, worked example, limitations, and even sibling tool differentiation. Nothing critical is missing.
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?
Input schema covers all 8 parameters with descriptions, but the description adds significant meaning: explains walk_away as reservation, target as aspiration, side as sell/buy, counterparty_offers as offers so far. Includes a worked example mapping parameters to realistic values.
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?
Title 'Negotiate — your optimal next move' and description state the tool computes the math-optimal next move in price negotiations. It specifies the verb (negotiate) and resource (single PRICE), and distinguishes from sibling tools like 'negotiate_bundle' for multi-issue bundles.
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?
Explicitly states when to use: 'haggling over a single PRICE across multiple back-and-forth rounds.' Also lists exclusions: not for one-shot/fixed prices, multi-issue bundles (use negotiate_bundle), or non-price decisions. Provides a validated edge and confidence interval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
negotiate_bundleNegotiate a bundle — logroll linked issuesARead-onlyInspect
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 design
(never worse than the closed form in-model; helps on a minority of deals).
Example: a SaaS contract — you most want a low price_per_seat, can flex on seats/term/SLA. negotiate_bundle(issues=[ {"name":"price_per_seat","options":["$50","$40","$30"],"my_utility":[0,0.5,1],"their_utility":[1,0.5,0]}, {"name":"sla","options":["99%","99.9%"],"my_utility":[0,1],"their_utility":[1,0]} ...], my_priorities={"price_per_seat":0.55,"sla":0.1,...}, their_offers=[...]) -> a full package that gives ground on SLA to hold the price.
| Name | Required | Description | Default |
|---|---|---|---|
| issues | 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 | No | Your best alternative to no deal, as a utility fraction in [0,1] (default 0.40); the returned package is guaranteed to beat it. | |
| compute_ms | No | EXPERIMENTAL. Milliseconds of rollouts to choose WHICH package to hold as they concede; 0 = instant closed-form package. | |
| rounds_left | No | Bargaining rounds remaining (used with compute_ms for the timing tier; default 8). | |
| their_offers | No | Packages the other side has tabled, oldest first, each as {issue_name: chosen_option} — lets it infer their priorities. | |
| my_priorities | No | {issue_name: weight} — how much each issue matters to you (any scale). Optional. | |
| their_batna_estimate | No | Your estimate of the other side's BATNA, [0,1] (default 0.40). |
Output Schema
| Name | Required | Description |
|---|---|---|
| fit | No | |
| error | No | |
| action | No | |
| compute | No | |
| message | No | |
| confidence | No | |
| my_utility | No | |
| trade_logic | No | |
| recommended_offer | No | |
| acceptance_probability | No | |
| their_expected_utility | No | |
| inferred_their_priorities | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details behavioral traits: free, no account needed, returns Pareto-efficient package, includes honest caveat about priority inference weakness, and explains optional timing refinement. It does not contradict annotations (readOnlyHint is reasonable for a computation tool).
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 description is lengthy but well-organized into sections (usage, validation, caveats, example). It is front-loaded with purpose and usage. Every sentence adds value, though could be slightly more concise.
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?
Given the complexity of multi-issue negotiation, the description is complete: covers purpose, usage, parameters, output, validation results, caveats, and an example. The output schema exists, but description still adds necessary trade-off logic context.
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?
Despite 100% schema coverage, the description adds significant meaning beyond schema: explains utility scales, issue structure, optional parameters like my_priorities and their_offers, and provides a detailed example. It fully compensates for any schema brevity.
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 clearly states the tool's purpose: 'Negotiate several linked issues at once by logrolling'. It uses specific verbs and resources, and distinguishes from sibling tool 'negotiate' which is for single price issues.
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 provides explicit when-to-use guidance: 'USE THIS WHEN: a deal has more than one issue on the table and they trade off... For a single PRICE, use negotiate instead.' It also gives examples like job offers and SaaS contracts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_dealScore a deal against the Pareto frontierARead-onlyInspect
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 | Required | Description | Default |
|---|---|---|---|
| issues | Yes | One dict per issue: {name, options, my_utility, their_utility} — both sides' TRUE per-option values (one number per option). | |
| package | Yes | The settled deal as {issue_name: chosen_option_label}. | |
| notional | No | Deal size in dollars, used for the 'dollars left on the table' framing (default 10000). | |
| my_weights | Yes | {issue_name: weight} — your true priorities (any scale). | |
| their_weights | Yes | {issue_name: weight} — their true priorities (any scale). |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| my_utility | No | |
| naive_split | No | |
| frontier_best | No | |
| joint_welfare | No | |
| their_utility | No | |
| logroll_capture | No | |
| frontier_capture | No | |
| dollars_left_on_table | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms this by stating it 'scores' a deal. It adds transparency with 'free, no account or key needed' and details the return values (e.g., 'realized joint welfare', 'dollars_left_on_table'), which go beyond annotations.
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 description is front-loaded with the purpose and key usage note ('free, no account or key needed'), followed by structured argument and return sections. It is concise for the complexity, though the argument list could be more compact.
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?
Given the tool's complexity (nested objects, metrics), the description covers inputs comprehensively, explains the analytical output, and provides conceptual background (Pareto frontier). It does not mention error scenarios but is otherwise complete.
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?
Despite 100% schema coverage, the description enriches parameter meaning, especially for 'issues' by specifying required sub-keys (name, options, my_utility, their_utility) and for weights by clarifying 'true priorities'. This adds nuance beyond the schema's basic descriptions.
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 clearly states 'Score how good a deal is against your floor/target' and 'Score a settled package against the exact Pareto frontier', specifying the verb and resource. It distinguishes from siblings like negotiate and negotiate_bundle, which create deals, but does not explicitly contrast with other scoring tools.
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 implies the tool is for post-settlement analysis ('Score a settled package'), but does not explicitly say when not to use it or provide alternatives. The phrase 'free, no account or key needed' indicates ease of use but not comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_adviseSession move — next single-price offerBInspect
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 | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | The API key that opened the session. | |
| my_offers | No | Your own offer history, in dollars, oldest first (optional). | |
| session_id | Yes | The session_id returned by session_open. | |
| rounds_left | No | Bargaining rounds remaining (optional). | |
| their_offers | Yes | The FULL counterparty offer history, in dollars, oldest first. |
Output Schema
| Name | Required | Description |
|---|---|---|
| why | No | |
| move | No | |
| error | No | |
| offer | No | |
| compute | No | |
| message | No | |
| receipt | No | |
| policy_id | No | |
| move_index | No | |
| context_hash | No | |
| confidence_note | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not clarify if the tool actually submits the move or merely advises. It mentions returning a move and message, which suggests advisory, but lacks explicit side-effect disclosure. The 'no additional charge' remark is helpful but insufficient.
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?
Two sentences that front-load purpose and provide key instructions and return details. Every word earns its place; no redundancy.
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?
Given 5 parameters, annotations, and an output schema, the description covers the core behavior and return structure. However, it omits error conditions, prerequisites (beyond session_open), and the advisory vs. execution nature, leaving some gaps.
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 coverage is 100%, so parameters are already documented. The description adds value by emphasizing 'FULL offer history' and 'oldest first' for 'their_offers' and optionally 'my_offers'. This provides usage nuance beyond the schema, but does not cover optional parameters like 'rounds_left'.
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 title and description clearly indicate this tool computes the next move in a single-issue session. The phrase 'next single-price offer' and 'Your next move' are specific. However, it lacks an explicit verb like 'computes' or 'returns', which slightly reduces clarity.
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 states to pass the full offer history each time, oldest first, and notes no additional charge. It distinguishes itself from bundle negotiation by specifying 'single-issue'. However, it does not explicitly exclude other scenarios or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_bundleSession move — multi-issue bundleAInspect
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 | Required | Description | Default |
|---|---|---|---|
| issues | Yes | One dict per issue: {name, options, my_utility (per option), their_utility (your read of their direction)}. | |
| api_key | Yes | The API key that opened the session. | |
| my_batna | No | Your BATNA as a utility fraction in [0,1] (default 0.40); the package is guaranteed to clear it. | |
| session_id | Yes | The session_id returned by session_open. | |
| cooperation | No | Optional cooperation dial in [0,1] biasing toward joint surplus. | |
| their_offers | No | Packages they've tabled, oldest first, each {issue_name: option} (optional). | |
| my_priorities | No | {issue_name: weight} — how much each issue matters to you (optional). | |
| their_batna_estimate | No | Your estimate of their BATNA, [0,1] (default 0.40). |
Output Schema
| Name | Required | Description |
|---|---|---|
| why | No | |
| move | No | |
| error | No | |
| message | No | |
| package | No | |
| receipt | No | |
| move_index | No | |
| context_hash | No | |
| confidence_note | No | |
| acceptance_probability | No | |
| their_expected_utility | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behaviors: deterministic closed-form (no rollout), BATNA enforcement, and return components (package, logic, priorities, probability, receipt). This adds significant value beyond annotations that only indicate readOnlyHint=false.
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 description is front-loaded with purpose and uses clear line breaks for key aspects. It is efficient but slightly wordy, with every sentence contributing meaning.
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?
Given 8 parameters, 3 required, and an output schema, the description covers input semantics, behavior, and return values comprehensively, leaving no significant gaps.
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 coverage is 100%, so baseline is 3. The description adds meaning by explaining the structure of 'issues' (name, options, utilities) and 'their_offers' (packages), going beyond the schema's brief descriptions.
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 clearly states the tool provides 'multi-issue logrolled advice' for trading issues in a session, distinguishing itself from siblings by noting it's the premium logrolling tier that the free tool lacks. The verb 'trade' and resource 'issues' are specific.
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 implies this tool is for premium logrolling when simpler negotiation won't suffice, contrasting with the free tool. It provides context on issue trading but lacks explicit 'when not to use' or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_closeClose session & get the signed receiptAIdempotentInspect
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 | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | The API key that opened the session. | |
| session_id | Yes | The session_id to close. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| closed | No | |
| receipt | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description details the return of closed flag and receipt, and explains the indistinguishable error behavior to prevent probing. No contradictions.
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 description is concise yet comprehensive, with each sentence adding value. It front-loads the main purpose and uses clear structure.
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 simple two-parameter tool with an output schema, the description fully explains the return values, security properties, and optional nature of the action. No gaps.
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 coverage is 100%, so the description does not need to add much. It only mentions the parameters implicitly by referring to 'api_key' and 'session_id', adding no new semantic detail beyond the schema.
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 clearly states the tool closes a session and returns a signed receipt. It uses specific verb+resource ('Close session') and distinguishes itself from siblings like session_open.
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?
Explicitly notes that closing is optional (sessions expire on their own) and explains the benefit of closing (timestamps for learning). Also warns about indistinguishable errors for unknown sessions or key mismatches, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_openOpen a $2 receipted sessionAInspect
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 | Required | Description | Default |
|---|---|---|---|
| seed | No | RNG seed for the deterministic engine (default 0). | |
| side | Yes | Which side you're on: 'buy' or 'sell'. | |
| target | Yes | Your aspiration price in dollars. | |
| api_key | Yes | Your SNHP API key; $2 is debited from its credit balance (covers every move of this one negotiation). | |
| category | Yes | Negotiation category for tuning: 'resale' | 'supply' | 'retail'. | |
| my_offers | No | Your own offers so far, in dollars, oldest first (optional). | |
| walk_away | Yes | Your true reservation in dollars — floor (sell) / ceiling (buy); private, never crossed. | |
| rounds_left | No | Bargaining rounds remaining for this move (optional; overrides the category default). | |
| their_offers | No | The other side's offers so far, in dollars, oldest first — pass to get the first move back with the session (optional). |
Output Schema
| Name | Required | Description |
|---|---|---|
| side | No | |
| error | No | |
| funding | No | |
| receipt | No | |
| category | No | |
| max_moves | No | |
| expires_at | No | |
| first_move | No | |
| how_to_pay | No | |
| session_id | No | |
| price_cents | No | |
| context_hash | No | |
| balance_after | No | |
| first_move_error | No | |
| price_millicents | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal; description adds that the session is deterministic, replayable, every move signed, walk_away is private, and cost covers up to 10 moves/7 days. No contradiction with annotations.
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?
Description is relatively long but well-organized with explicit details. Some redundancy (e.g., cost repeated), but front-loaded with purpose.
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?
Given the complexity (9 params, 5 required, output schema present), the description covers cost, constraints, behavioral traits, and sibling tool linkage, making it fully adequate for an agent.
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?
Input schema has 100% description coverage, so description adds limited extra meaning. It clarifies that passing their_offers gets first move back, but overall parameter semantics are already well-covered by schema.
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 clearly states 'Open a $2 receipted negotiation session' and distinguishes it from siblings like session_advise (for subsequent moves) and session_close. It specifies deterministic, replayable, signed moves, making the purpose unambiguous.
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?
Explicitly mentions the $2 cost, credit requirement, and advises topping up before use. Directs subsequent moves to session_advise. No when-not statement, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stable_matchStable matching (Gale–Shapley)ARead-onlyInspect
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 | Required | Description | Default |
|---|---|---|---|
| proposers | 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 | Yes | List of {id, preferences:[...], capacity (optional, default 1)}. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| matching | No | |
| n_proposals | No | |
| blocking_pairs | No | |
| unmatched_proposers | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true and openWorldHint=false, description details the algorithm's properties (proposer-optimal, free, no account needed), return fields (matching, unmatched_proposers, blocking_pairs, n_proposals). No contradiction with annotations.
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?
Description is front-loaded with purpose, then usage, parameter format, output, and example. Every sentence is necessary and no fluff.
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?
Covers all key aspects: purpose, when to use, parameter semantics, output structure, and example. Slight lack of error handling or edge cases, but sufficient for a well-defined algorithm.
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 coverage is 100%, but description adds meaning: explains the format of proposers and receivers, notes capacity is optional, and highlights proposer-optimality. Example clarifies usage beyond schema.
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 clearly states it matches two groups by rankings to achieve stable matching, with concrete examples (interns-teams, students-schools). It distinguishes from sibling tools which focus on auctions, negotiations, or memory/storage.
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?
Explicitly says 'USE THIS WHEN' and lists appropriate scenarios. Lacks explicit 'when not to use' but context makes it clear it's for bipartite matching with preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
store_catalogStore catalog & wallet balanceARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| keys | No | |
| unit | No | |
| error | No | |
| slots | No | |
| admission | No | |
| counter_fee | No | |
| paid_session | No | |
| starter_credit | No | |
| counter_fee_pct | No | |
| request_privacy | No | |
| millicents_per_cent | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint: true) by detailing the charging model (pay only on delivery, no per-call markup), fee structure, starter credit, and that it never returns key material. No contradiction with annotations.
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 description is detailed and informative, but slightly verbose. It front-loads the key purpose and then explains the store model. Every sentence adds value, but some could be consolidated for brevity.
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?
Given no parameters and the presence of an output schema, the description fully explains the returned information (money unit, per-slot details, pricing facts) and the context (store model, fee structure). It is complete for agent understanding.
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?
The tool has zero parameters, so the baseline is 4. The description adds context about what is returned but no parameter definitions are needed since schema coverage is 100%.
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 clearly states the tool's purpose: 'See what's on the shelf — free, no key needed: prices, predicates, receipt scheme, and your balance.' It uses a specific verb ('see') and resource ('shelf'), and distinguishes itself by noting it never returns key material and covers the whole shelf in one read.
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 provides some guidance by suggesting 'store_request logs it' when a needed capability is missing, hinting at an alternative. However, it does not explicitly contrast with all sibling tools like auction_bid or negotiate, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
store_requestRequest a capability / check a filingAInspect
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 | Required | Description | Default |
|---|---|---|---|
| text | No | What capability you want that we don't stock yet (free-text). Omit when re-querying with request_id. | |
| watch | No | Set True (with an api_key) to flag the ask for a status-flip heads-up; anonymous watches are ignored. | |
| api_key | No | Your SNHP API key (optional; required only if you set watch=True). | |
| request_id | No | Pass an existing filing id to RE-QUERY its status instead of filing a new request. |
Output Schema
| Name | Required | Description |
|---|---|---|
| door | No | |
| text | No | |
| check | No | |
| error | No | |
| found | No | |
| watch | No | |
| status | No | |
| filed_at | No | |
| request_id | No | |
| status_note | No | |
| same_ask_count | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal, but description adds significant context: filing logs verbatim, returns specific fields, watch only works with api_key, poll-based no push. No contradictions with annotations.
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?
Description is long but well-organized and front-loaded. Could be slightly more concise, but every sentence adds value.
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?
Given the tool's complexity (dual-mode, 4 params, output schema implied), the description is complete. Output fields are listed, usage paths are clear, and no gaps remain.
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 coverage is 100%, but description adds crucial meaning: text omitted when re-querying, watch condition, api_key requirement, request_id purpose. This far exceeds the baseline 3.
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 clearly states the tool does two things: filing a new request or re-querying an existing request's status. It uses specific verbs ('Request a capability / check a filing') and distinguishes itself from siblings like store_catalog.
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?
Explicitly tells when to use each mode: pass request_id to re-query, otherwise file a new ask. It mentions absorbing old tools and provides details on watch and api_key conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseBqualityDmaintenanceEquilibrium-aware primitives for AI agents — negotiation, auctions, mechanism design — exposed over MCP and importable as a Python library.10Apache 2.0
AIﾉアカリ☆ MCPofficial
Flicense-qualityBmaintenanceRemote MCP server providing free tools for value-bearing responses and trust receipts, plus optional consent-based commerce, enabling agents and humans to connect to a coordinated AI operator.- Alicense-qualityAmaintenanceAgent Negotiation - MCP server providing AI-powered tools and automation by MEOK AI Labs10MIT
Your Connectors
Sign in to create a connector for this server.