Skip to main content
Glama

SNHP — free negotiation math + agent memory

by io.github.ryuxik

Revenue-optimal reserve price

auction_reserve
Read-only

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}}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
n_biddersYesHow many bidders you expect.
seller_valuationYesWhat the item is worth to YOU, in dollars (your floor).
bidder_value_priorYesRough model of what bidders will pay, e.g. {family:'uniform', params:{low:2000, high:8000}}.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
rationaleNo
reserve_priceNo
expected_revenueNo
expected_efficiency_lossNo
expected_revenue_no_reserveNo

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All SNHP — free negotiation math + agent memory toolsInspect
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.

Resources