SNHP — negotiation rules your AI can't break

Name: SNHP — negotiation rules your AI can't break
Author: ryuxik

Server Details

Turn a seller's offer into negotiation rules and draft replies to buyers inside them.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 58 days
Last Tested: 2026-10-14 08:54
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: ryuxik/snhp
GitHub Stars: 0
Server Listing: SNHP

TDQS

A4.2/5.0

Scored 2026-10-07 15:30 across 4 tools

Disambiguation4/5

Each tool targets a distinct step: compile (create policy), check (validate edited policy), draft (generate reply), verify (audit receipt). The only mild overlap is between compile_offer_policy and check_offer_policy, but the descriptions explicitly clarify that compile creates rules while check validates an edited set.

Naming Consistency5/5

All four names follow a clean verb_noun snake_case pattern (check_offer_policy, compile_offer_policy, draft_negotiation_reply, verify_deal_receipt). The convention is applied uniformly with no deviations or mixed casing.

Tool Count4/5

Four tools map neatly onto a coherent pipeline (compile → check → draft → verify) with no redundant surface. It is slightly lean, but each tool clearly earns its place and none feel gratuitous.

Completeness4/5

The set covers the full negotiation lifecycle: authoring a policy, validating it, drafting replies against it, and verifying signed receipts. Minor gaps exist around persistence/listing of policies (the server is stateless and relies on passed state), but core workflows are well covered.

Available Tools

4 tools

check_offer_policyCheck a negotiation policyA

Read-only

Inspect

Check an edited negotiation policy: returns {ok, policy, issues, summary}. No model call, free.

USE THIS WHEN: you changed a policy from compile_offer_policy (a floor, an option, a forbidden combination) and want to know it is valid and what it now allows before using it in draft_negotiation_reply.

ParametersJSON Schema

Name	Required	Description	Default
`policy`	Yes	A policy object from compile_offer_policy, edited or not.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`error`	No
`issues`	No
`policy`	No
`served`	No
`summary`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered structurally. The description adds genuinely new context: no model call and no cost, plus the response contract. It doesn't discuss failure modes or what an invalid policy returns, but with annotations carrying the safety profile this is solid.

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?

Well front-loaded: capability and cost first, then the usage trigger. The enumeration of return keys is mildly redundant since an output schema exists, but the text is short and every other sentence earns its place.

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?

For a one-parameter validation tool with an existing output schema and clear annotations, the description supplies everything an agent needs: purpose, cost/latency profile, when to call it, and its place in the compile→check→draft workflow.

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?

Single required parameter with 100% schema description coverage, so the schema already explains that "policy" is "a policy object from compile_offer_policy, edited or not." The description's "edited" phrasing reinforces this but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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?

States a specific verb+resource ("Check an edited negotiation policy") and immediately names the return shape {ok, policy, issues, summary}. It also differentiates itself behaviorally from heavier siblings with "No model call, free," so an agent can place it without opening the schema.

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 USE THIS WHEN block gives an explicit trigger ("you changed a policy from compile_offer_policy") and an explicit downstream condition ("before using it in draft_negotiation_reply"). Both the predecessor and successor tools are named, so routing is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compile_offer_policyCompile an offer into negotiation rulesA

Read-only

Inspect

Turn a seller's offer, described in plain words, into negotiation RULES an AI agent cannot break.

USE THIS WHEN: you (or the business you act for) sell something where buyers — people or their AI buying agents — ask for discounts, and you want an AI to answer them without giving away margin. Describe the offer: the listed price, the lowest price you'd take for a plain deal, what you'd trade a discount for (financing with you, a trade-in, a longer commitment, paying sooner, buying this week…), extras you can add and what they cost you, and anything never on the table. Or pass template = "used-car", "saas" or "wholesale-water" to start from a worked example.

Compiling a description runs a language model and needs an access_key (pilot businesses get one at https://snhp.dev/#pilot); templates are free.

Returns {ok, policy, issues, summary}: policy is the machine-readable rule set (pass it to draft_negotiation_reply), summary restates the floor, walk-away, what can be traded and the limits in plain words, and issues lists what to fix before going live (e.g. a floor below cost).

ParametersJSON Schema

Name	Required	Description
`template`	No	Instead of a description: 'used-car', 'saas' or 'wholesale-water' (free, no key).
`access_key`	No	Your SNHP access key — needed to compile a description (it runs a language model). Pilot businesses get one at https://snhp.dev/#pilot.
`description`	No	Your offer in plain words: listed price, the lowest you'd take for a plain deal, what you'd trade a discount for, extras you can add and their cost, what is never on the table.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`error`	No
`issues`	No
`policy`	No
`served`	No
`summary`	No

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial non-obvious behavior: compiling a description invokes a language model and requires an access_key, templates are free, and the result includes an `issues` list flagging problems like a floor below cost. These cost/auth/validation traits go well beyond what the annotations disclose.

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?

Well front-loaded: purpose first, then a clearly labeled when-to-use block, then cost/auth, then returns. It is on the long side and the 'Returns {ok, policy, issues, summary}' section is partly redundant given an output schema exists, but each sentence carries information an agent would otherwise have to guess.

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 a 3-param, zero-required, no-enum tool with a full output schema, the description supplies everything missing: which input mode to pick, the auth requirement, the cost model, and the semantic content of the return fields. Nothing an agent needs to select and invoke this correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 100%, so the schema documents all three parameters, making 3 the baseline. The description adds meaning by enumerating what a good `description` should contain (listed price, floor, tradeables, extras and their cost, off-limits items) and by surfacing the three concrete template values, which goes beyond the raw schema text.

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 opening sentence states a specific verb and resource — turning a plain-language seller offer into negotiation rules — and the framing 'RULES an AI agent cannot break' makes the output artifact concrete. It is clearly distinguishable from siblings like check_offer_policy (validation) and draft_negotiation_reply (which consumes this tool's output).

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?

An explicit 'USE THIS WHEN' block names the scenario (selling something where buyers or their agents haggle), and it routes between the two input modes — a free-form description vs. a named template. It even names the downstream sibling (draft_negotiation_reply), so the agent knows where the result flows.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

draft_negotiation_replyDraft a reply to a buyer, inside your rules

Read-only

Inspect

Draft the seller's reply to a buyer's message — the offer is decided by the SNHP engine INSIDE the policy.

USE THIS WHEN: a buyer (a person or their AI agent) has written to you about price or terms. Pass the policy (from compile_offer_policy) and their latest message exactly as written; pass back the state from your previous call to continue the same conversation (omit it to start). flags is what YOUR records confirm about the buyer (e.g. {"new_customer": true}) — never what the buyer merely claims. stock is the current stock of what the policy's inventory binds, sent with every message (schema.org Offer, Google Merchant or a plain feed record): nothing out of stock is offered, and a deal is signed only on fresh records that say it can be sold.

Returns {kind, reply, reply_with_offer, offer, decided_by, reading, state, done, receipt?}: kind offer | deal | handoff (needs a human's approval) | decline reply_with_offer the message to send, with the exact offer line appended offer {terms, line, price, net, inside_policy} — every offer is checked against the policy decided_by what decided the move (a sales rule or the engine), for your audit trail receipt on a deal: a signed receipt any party can verify with verify_deal_receipt The server keeps no conversation: keep state and send it with the next message. Needs an access_key (pilot businesses get one at https://snhp.dev/#pilot).

ParametersJSON Schema

Name	Required	Description
`flags`	No	What YOUR records confirm about this buyer, e.g. {"new_customer": true}.
`state`	No	The `state` from your previous call in this conversation; omit to start.
`stock`	No	Current stock records for what the policy's inventory binds, with every message (schema.org Offer, Google Merchant or {id\|vin, status}): nothing out of stock is offered or signed.
`engine`	No	The engine that decides offers; empty = the policy's own (templates set their tested default), else 'bundle3'.
`policy`	Yes	The policy from compile_offer_policy.
`message`	Yes	The buyer's latest message, exactly as written.
`access_key`	No	Your SNHP access key (drafting runs a language model). Pilot businesses get one at https://snhp.dev/#pilot.

Output Schema

ParametersJSON Schema

Name	Required	Description
`done`	No
`kind`	No
`menu`	No
`error`	No
`offer`	No
`reply`	No
`state`	No
`engine`	No
`writer`	No
`reading`	No
`receipt`	No
`decided_by`	No
`reply_with_offer`	No

verify_deal_receiptVerify a deal receiptA

Read-only

Inspect

Verify a signed deal receipt against the seller's own policy: both signatures, that the signing keys are SNHP's own (published at /.well-known/ucp), the policy digest, and every rule re-checked from the package. Returns {ok, problems, checks, signed_by_snhp, signatures}. Free, no model call.

ParametersJSON Schema

Name	Required	Description
`flags`	No	The account record used for the deal, if any.
`policy`	Yes	The policy the deal was made under.
`receipt`	Yes	The receipt returned with a deal.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`error`	No
`checks`	No
`problems`	No
`signatures`	No
`signer_kids`	No
`signed_by_snhp`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful context beyond that: it is 'Free, no model call', and the signing keys come from SNHP's published /.well-known/ucp endpoint. It does not discuss failure modes beyond the names of the problem categories.

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?

Two dense sentences, front-loaded with the verification scope, then cost and return shape. Listings of return fields ('{ok, problems, checks, signed_by_snhp, signatures}') is slightly redundant given an output schema exists, but the text is tight and earns most of its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, annotations, and fully documented parameters, the description carries little remaining burden and is essentially complete. Repeating the return object is harmless but unnecessary; nothing an agent needs to invoke it is missing.

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?

Schema description coverage is 100% and the description largely mirrors it ('the seller's own policy', 'the receipt returned with a deal'). It adds no syntax, format, or shape detail beyond what the schema already provides, so the baseline 3 is appropriate.

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?

States a precise verb ('Verify') and resource ('signed deal receipt') and enumerates exactly what is checked: both signatures, key ownership against /.well-known/ucp, policy digest, and rule re-checks. An agent can tell this apart from check_offer_policy/compile_offer_policy at a glance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the domain ('the receipt returned with a deal', 'the policy the deal was made under'), but there is no explicit when-to-use, when-not-to-use, or named alternative among the siblings (check_offer_policy, compile_offer_policy). Adequate but leaves routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 13, 2026

Changeddraft_negotiation_reply1 field changed

addedInput schema / properties / stock

Added value: +{
+  "anyOf": [
+    {
+      "items": {},
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Current stock records for what the policy's inventory binds, with every message (schema.org Offer, Google Merchant or {id|vin, status}): nothing out of stock is offered or signed.",
+  "title": "Stock"
+}

2 tool updatesOct 7, 2026

Changeddraft_negotiation_reply1 field changed

changedInput schema / properties / engine / description

Previous value: -"The engine that decides offers; empty = the policy's own (templates set their tested default), else 'v10'."New value: +"The engine that decides offers; empty = the policy's own (templates set their tested default), else 'bundle3'."

Changedverify_deal_receipt3 fields changed

addedOutput schema / properties / signatures

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Signatures"
+}

addedOutput schema / properties / signed_by_snhp

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Signed By Snhp"
+}

addedOutput schema / properties / signer_kids

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Signer Kids"
+}

1 tool updateOct 6, 2026

Changeddraft_negotiation_reply1 field changed

addedOutput schema / properties / menu

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Menu"
+}

11 tool updatesOct 6, 2026
- Removedmemory_load
- Removedmemory_save
- Removednegotiate
- Removednegotiate_bundle
- Removedscore_deal
- Removedsession_advise
- Removedsession_bundle
- Removedsession_close
- Removedsession_open
- Removedstore_catalog
- Removedstore_request
8 tool updatesOct 5, 2026
- Removedauction_bid
- Removedauction_reserve
- Addedcheck_offer_policy
- Removedclearance_price
- Addedcompile_offer_policy
- Addeddraft_negotiation_reply
- Removedstable_match
- Addedverify_deal_receipt
15 tool updatesJul 24, 2026
- First observedauction_bid
- First observedauction_reserve
- First observedclearance_price
- First observedmemory_load
- First observedmemory_save
- First observednegotiate
- First observednegotiate_bundle
- First observedscore_deal
- First observedsession_advise
- First observedsession_bundle
- First observedsession_close
- First observedsession_open
- First observedstable_match
- First observedstore_catalog
- First observedstore_request

Related MCP Connectors

Focxle: negotiation rooms and locked agreements for B2B AI agents A
com.focxle
Negotiate B2B deals agent to agent: every offer recorded, owner rules checked, agreements locked.
Autonomous Agents Legal & Compliance
161
zopaf A
io.github.rjandino
Negotiation math engine. Pareto frontier, counteroffer generation, zero LLM tokens.
AI & Machine Learning Finance
2
reservoprix A
com.spocont
Sell to the best offer: a sealed-offer link and button for any listing, with a hidden reserve price.
E-commerce & Retail
21
Nexez Agentic Commerce A
ai.nexez
Find Nexez sellers, inspect offers, and validate checkout or negotiation before buyer approval.
E-commerce & Retail Search
52

Related MCP Servers

genpark-agentic-negotiationofficial
Autonomous Agents App Automation
Alpha-Park
A
license
Not graded
quality
B
maintenance
Enables autonomous multi-turn negotiation and counter-offer strategy by calculating ZOPA, concession decay curves, reservation price thresholds, and structured bargaining offers.
Updated 10 days ago (2026-10-03 23:50 UTC)
7
MIT
Negotiator MCP Server
E-commerce & Retail App Automation
jayblast-spec
A
license
Not graded
quality
C
maintenance
Enables natural-language price negotiation by turning purchase requests into ranked cheapest-first estimates and drafting vendor messages.
Updated a month ago (2026-09-07 13:23 UTC)
Apache 2.0
genpark-agentic-negotiationofficial
Autonomous Agents CRM
alphaparkinc
A
license
Not graded
quality
B
maintenance
Enables autonomous multi-turn negotiation by calculating the Zone of Possible Agreement, modeling concession decay curves, enforcing reservation price thresholds, and generating structured bargaining counter-offers. It supports agentic commerce and contract negotiation workflows through a native MCP interface.
Updated 10 days ago (2026-10-03 23:49 UTC)
7
MIT
ShelfGap Buyer Lens
keskinonur
A
license
Not graded
quality
D
maintenance
A deterministic buyer-choice simulator inside ChatGPT that compares merchant offers against user-supplied alternatives, explains wins/losses, and tests what-if changes.
Updated 3 months ago (2026-07-20 21:05 UTC)
MIT