parley-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| parley_decideA | Reach a decision among parties with conflicting interests. Give the options and each party's red lines (hard constraints, checked in code) and soft preferences. An option that crosses any party's red line is rejected outright; among the options acceptable to everyone the max-min rule picks the one whose least-satisfied party is best off, tie-broken by total score. No option acceptable to all parties yields an honest status 'deadlock' with decision null, never a forced choice. Returns JSON: status ('agreed'|'deadlock'), decision (the winning option object or null), transcript (every option with each party's masked verdict), and transcript_sha256 (the receipt hash; keep it to verify the transcript later with parley_verify_receipt). HONESTY NOTE: in this mode you, the caller, hold every party's spec and pass them all in one call, so there is no privacy between parties or from you. What still holds: red lines reject an option deterministically (a violating option cannot win), the max-min rule picks among options feasible for everyone, and the returned transcript is tamper-evident via transcript_sha256, provided the hash is kept by someone other than whoever might edit the transcript (it is unsigned and this server does not store it). For private sheets run one process per owner: examples/run_env.py. |
| parley_verify_receiptA | Two independent checks on a transcript from parley_decide. Returns JSON: match, max_min_verified, expected_sha256, recomputed_sha256. match=true means only that this transcript hashes to the sha256 you passed. The hash is unsigned and this server does not store it, so if the transcript and the hash come from the same party, match proves nothing: whoever edits the record can re-hash it. It detects tampering only when the hash was kept by someone other than whoever could edit the transcript. max_min_verified recomputes the decision from the recorded verdicts: true when the announced result is exactly the max-min option over them (or an honest deadlock), false when the announced winner does not follow from the recorded verdicts. Verdicts are unsigned, so whoever can rewrite the record can rewrite them to fit a swapped winner; only a hash kept by another party, or signed verdicts, rules that out. It needs every entry to carry exactly one verdict per owner. Pass expected_owners (the roster you know took part) so a record missing a whole owner also fails; that roster is only as trustworthy as where you got it. A malformed transcript is a tool error, not a mismatch. |
| parley_check_partyA | Replay one party's red lines against a decision: did the outcome cross any of them? Pass the party's spec (the same object you would put in parley_decide's parties) and the decision object returned by parley_decide. Returns JSON: owner and holds (true when every red line of that party holds on the decision). A null decision (deadlock) forces nothing on anyone, so holds is true. Soft preferences are not judged here, only red lines. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools have distinct targets: parley_decide produces a decision, parley_verify_receipt re-checks the full transcript/hash and max-min, and parley_check_party replays one party's red lines. There is mild overlap between the two verification tools, but the descriptions clearly delineate what each checks.
All three names follow a single, predictable pattern: parley_ prefix plus a consistent verb_noun form (decide, verify_receipt, check_party). No mixed conventions or vague verbs.
Three tools is on the thin side, but the domain is a narrow, self-contained decision engine, and decide/verify/check each earns a clear place. It is a touch under-provisioned rather than bloated.
The surface covers the core lifecycle: reach a decision, verify the recorded transcript, and re-check a single party. Privacy-mode execution is delegated to examples/run_env.py rather than a tool, and there is no batch check, but nothing leaves an obvious dead end for the stated purpose.