SNHP — negotiation rules your AI can't break

Draft a reply to a buyer, inside your rules

draft_negotiation_reply

Read-only

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

Input 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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

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"
+}

Changed1 schema field changedOct 7, 2026

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'."

Changed1 schema field changedOct 6, 2026

addedOutput schema / properties / menu

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

AddedOct 5, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only give readOnlyHint and openWorldHint, so the description carries most of the weight and delivers: it discloses that no conversation is kept server-side (state must be carried), that out-of-stock items are never offered or signed, that deals need fresh records and human approval in the handoff kind, and that an access_key is needed. It omits rate limits, latency or cost of the drafting LLM call, which is why it is not a 5.

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?

Front-loaded with the core purpose, then a clearly separated USE THIS WHEN block. It is dense and long, but every section (when-to-use, per-parameter semantics, return shape) earns its place; the decline/handoff enumeration and receipt note are slightly verbose.

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 7-parameter tool with nested objects and an output schema, the description covers the trigger, every input's provenance, state-carrying semantics, stock freshness rules, auth, and the return contract. Even though an output schema exists, it explains the meaning of kind, decided_by and the receipt, so an agent can act on the result.

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 coverage is 100%, so the structured fields already define all 7 parameters and the baseline is 3. The description adds meaning beyond that: flags must be what YOUR records confirm, never buyer claims; stock must be sent with every message; engine empty means the policy's own default. Only the access_key usage is mostly a restatement of the 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?

States a specific verb and resource ('draft the seller's reply to a buyer's message') and immediately pins the mechanism: the offer is decided by the SNHP engine inside the policy. This distinguishes it from compile_offer_policy and check_offer_policy among siblings.

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 states the trigger (a buyer wrote about price/terms) and each input's provenance: policy from compile_offer_policy, state from your previous call, omit state to start. It even names the exclusion of claims-based flags. Nothing is left to inference.

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

All SNHP — negotiation rules your AI can't break tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.