SNHP — free negotiation math + agent memory

Open a $2 receipted session

session_open

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

TableJSON Schema

Name	Required	Description	Default
`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

TDQS

A4.1/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All SNHP — free negotiation math + agent memory tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Open a $2 receipted session

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources