Skip to main content
Glama
5uper0

parley-mcp

by 5uper0

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessUnresponsive