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
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
Score is being calculated. Check back soon.
Available Tools
15 toolsauction_bidOptimal auction bidRead-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 |
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?
Annotations already declare readOnlyHint=true, indicating no destructive side effects. Description adds transparency by stating it's free and requires no account or key. It does not mention rate limits or other constraints, but for a computation tool this is adequate.
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 lead sentence, usage block, parameter breakdown, and example. It is slightly verbose but not wasteful; every sentence adds value. Could be more concise but remains readable.
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 and annotations, the description covers all needed aspects: purpose, usage conditions, parameter details, and a worked example. No gaps remain for an AI agent to understand how to use this tool effectively.
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%, and description adds significant meaning beyond the schema: it provides a concrete example of the complex 'bidder_value_prior' object with family and params, explains seller_valuation as 'what it's worth to YOU', and gives an end-to-end example call that ties parameters to use case.
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 auctions. It distinguishes itself from sibling tools like 'negotiate' by specifying it's for auctions with multiple bidders, 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?
Description explicitly tells when to use (auction with multiple bidders) and when not to (one-on-one haggling), and directs to the alternative 'negotiate'. Example usage further clarifies appropriate scenarios.
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 scheduleRead-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 |
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?
Exceeds annotations by detailing return format, error cases (wrong owner, expired TTL, key unavailable), and cost (free). No contradiction with readOnlyHint.
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 bullet points for return and errors. Slightly lengthy but front-loaded and 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 output schema exists, description adequately covers parameters, return values, and error conditions. No gaps identified.
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 value by explaining the api_key's behavior with wrong ownership and the ticket's origin (from memory_save).
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?
Description clearly states the action (load a memory), the resource (memory saved earlier), and the retrieval being free. It distinguishes from the sibling memory_save tool.
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?
Describes when to use (earlier session save) and implies prerequisites (ticket, api_key). Does not explicitly state when not to use, 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.
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?
The description goes far beyond annotations, detailing encryption before saving, blind custody (store cannot read), receipt signing, charging details (thin flat fee only on durable store, no charge for empty/oversize/unencodable), ttl clamping, and returned expires_at. 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 front-loaded with the core purpose and then dives into details. While somewhat long, every sentence adds value and there is no redundancy. It could be slightly more concise but remains 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?
For a tool with moderate complexity (3 params, output schema exists), the description covers all necessary aspects: purpose, security, cost, parameter constraints, and return values (expires_at, receipt). It is fully self-contained and leaves no major ambiguity.
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 value by explaining the rationale for encryption (keys never transit), the starter credit for new keys, and the clamping of ttl_seconds. It provides context that the schema alone does not convey.
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: persistent memory across sessions. It explicitly distinguishes from the sibling tool memory_load (which is free) and explains the blind locker concept. The verb 'save' is specific and the title adds context.
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 tells when to use this tool: for saving memory that persists across sessions. It contrasts with memory_load (free) and explains costs and credits. It lacks explicit when-not-to-use guidance but provides sufficient context for informed use.
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 moveRead-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 |
negotiate_bundleNegotiate a bundle — logroll linked issuesRead-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 |
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 already declare readOnlyHint true, so no contradiction. Description adds behavioral details: uses true utility values, computes Pareto frontier, dollars left on table. Provides transparency 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?
Well-structured with Args and Returns sections, but somewhat verbose. Appropriate for a complex tool with nested parameters. Every sentence earns its place, 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?
Completely describes input structure, output values, and purpose. For a tool with 5 parameters, nested objects, and output schema, the description covers all necessary context without relying on the output schema (which is present but not shown).
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 description coverage is 100%, so baseline 3. Description adds extra meaning for parameters, e.g., explaining that issues require true per-option values, and weights are true priorities. Adds context not in schema definitions.
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?
Clearly states it scores a deal against the Pareto frontier, with specific verb 'Score' and resource 'deal against the Pareto frontier'. Differentiates from sibling tools like 'negotiate' and 'auction_bid' by its evaluative nature.
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 to use for settled packages and mentions it's free with no account needed. Implied context of post-negotiation evaluation, but no explicit when-not-to-use or alternative tools listed.
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 offerAInspect
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?
The description adds behavioral context beyond annotations: it notes there is 'no additional charge' and lists the return fields (move, price, message, receipt). Annotations already indicate non-read-only, non-destructive, so the description supplements with cost and output structure.
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 extremely concise at three sentences, with the most important information first ('Your next move inside a receipted session'). Every sentence adds necessary detail without 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 the tool has 5 parameters (3 required) and an output schema, the description adequately covers the essential usage: what to provide (full offer history) and what to expect (move, price, message, receipt). It does not delve into output schema details, but that is addressed separately.
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?
With 100% schema coverage, the schema already documents parameters. The description adds value by emphasizing that 'their_offers' must be the FULL history and oldest first, and clarifies that 'my_offers' is optional. This extra context improves parameter understanding.
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 the next move in a receipted single-issue session, distinguishing it from siblings like 'negotiate_bundle' and 'session_open'. The title reinforces this by specifying 'next single-price offer'.
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 instructs to 'Pass the FULL offer history each time, oldest first', which guides usage. However, it does not explicitly contrast with alternatives or state when not to use, but the context of siblings provides implicit differentiation.
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?
Annotations are minimal (readOnlyHint=false, etc.), so the description carries the burden. It reveals key behavioral traits: deterministic closed form (no randomness), guaranteed to clear stated BATNA ('enforced, not promised'), and returns specific outputs (trade logic, inferred priorities). No destructive or side-effect info needed. Adds significant transparency 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 concise yet comprehensive, with no wasted words. It is front-loaded with purpose, then details inputs and outputs. Every sentence adds value: explaining what it does, what it doesn't have (free tool), input format, output components, and guarantees. Efficient and well-organized.
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 complexity (8 params, 3 required, no enums, with output schema), the description covers core functionality and return values. It explains the mathematical guarantee and input structure. However, it assumes knowledge of 'receipted session' and does not link to session lifecycle tools (e.g., session_open/close). Minor gaps but adequate for an AI agent familiar with the session concept.
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 'issues' array format in detail and the purpose of 'their_offers' and 'my_priorities'. It clarifies that 'my_batna' default is 0.4 and that the package clears it. This goes beyond the schema's descriptions, which are concise but less context-rich.
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: multi-issue logrolled advice inside a receipted session. It distinguishes itself from a 'free tool' that lacks logrolling, and the title 'multi-issue bundle' sets it apart from siblings like 'negotiate_bundle' and 'session_advise'. The verb 'trade' and specific input-output description make 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?
The description implies use for logrolling multi-issues ( 'trade the issues you care less about for the ones you value' ). It mentions a 'free tool' that doesn't have this tier, suggesting this is the advanced version. However, it does not explicitly state when not to use it or provide alternative sibling tools for simpler scenarios. No exclusions or explicit when-to-use guidance, 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.
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?
The description discloses error behavior (indistinguishable errors for unknown session or key mismatch), idempotency implications, and return values (closed flag and signed receipt), adding significant value beyond annotations. Annotations only indicate idempotentHint=true and non-destructive.
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 the main action upfront. It is somewhat verbose but every sentence serves a purpose, explaining optionality, benefits, and error handling.
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 adequately covers the tool's behavior. It explains what happens on success and failure, though some internal details (GAUNTLET #4) may be unclear without 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?
Schema coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning beyond 'api_key' and 'session_id', only referencing 'key mismatch' errors indirectly. Baseline score of 3 is appropriate.
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 'Close session & get the signed receipt' and description explicitly state the action and result. It clearly distinguishes from sibling tools like session_open and session_advise by focusing on closing and receipt retrieval.
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 notes that closing is optional and sessions expire automatically, providing a usage context. However, it does not explicitly state when to use over alternatives or when not to 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 provide no hints, so the description carries full burden. It discloses paid nature, determinism, replayability, signature, limitations (10 moves, 7 days), credit balance requirement, and the walk_away privacy. 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 somewhat lengthy but well-structured (summary then bullet details). Every sentence adds value; minimal redundancy. Could be slightly more compact, but 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's complexity (9 params, 5 required, output schema exists), the description covers key behaviors, parameter usage, and flow. No gaps identified; sufficient 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?
Schema coverage is 100% but the description adds significant context: explains the $2 cost covers all moves, passing their_offers retrieves first move, and clarifies walk_away concept. Adds meaning beyond 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 'Open a $2 receipted negotiation session' along with key properties like deterministic, replayable, and signed. It also distinguishes from the sibling tool session_advise, which handles subsequent moves.
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 that subsequent moves use session_advise and that a new key's starter credit is insufficient, implying when not to use this tool. Clear context on cost and prerequisites, but lacks explicit 'use this when...' phrasing.
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)Read-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 |
store_catalogStore catalog & wallet balanceRead-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 |
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?
Discloses mutation (filing) and non-destructive reads (re-query). Explains return shapes for both modes, logging behavior, size caps, and that filings are not rendered raw. No contradiction with annotations, which are generic.
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 lengthy but well-organized, with front-loaded purpose. Each sentence adds value, though some technical details (e.g., GAUNTLET #5) could be omitted for conciseness.
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 both use cases fully, explains return formats, mentions public endpoints for checking all filings, and provides context on how demand drives stocking. Output schema exists but description complements it well.
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 covers 100% of parameters, so baseline is 3. Description adds value by explaining the dual-purpose logic (text omitted when re-querying) and the condition for watch to be effective (requires api_key).
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 dual purpose: filing a new request or re-querying an existing filing. It distinguishes between the two modes based on the request_id parameter, and the title reinforces this. The sibling tools are different, so no confusion.
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?
Explicit guidance on when to use each mode: 'pass request_id to RE-QUERY' vs. 'Without a request_id it FILES a new ask'. Also specifies conditions for watch=True and api_key requirement, and mentions poll-based status checking via store_my_requests.
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!