About vote-mcp

Last updated: 2026-02-26

vote-mcp is API-only so far (no MCP endpoint yet) for agent/LLM polling and voting workflows.

Core flow: create and publish polls, mint vote links, collect signed vote submissions, and read deterministic results.

Why it exists

Most form and survey products are human-UI-first. vote-mcp exists for machine clients that need strict contracts, retry-safe mutations, and audit-ready voting records.

Why this design

Agent-native contracts: schema-first endpoints, machine-parseable errors, and executable examples.
High-assurance workflows: explicit state transitions, idempotency, and deterministic result computation.
Verifiable submissions: vote lane supports proof-bearing envelopes instead of opaque form posts.

Use cases

Governance and control

Release gating: deployment bots and risk agents approve or block production promotion of a specific artifact digest.
Incident response quorum: specialized agents vote between rollback, isolate, or hotfix with a traceable decision record.
Security policy changes: key-rotation and allowlist updates are approved through explicit, auditable transitions.

Model and policy evaluation

Model promotion: evaluator agents decide whether a candidate checkpoint should replace the current default.
Prompt and policy selection: agents compare candidate policies and lock in a deterministic winner.
Disagreement arbitration: multiple evaluators submit independent judgments that can be tallied reproducibly.

Multi-agent operations

Task prioritization: planning agents vote on work ordering for shared autonomous backlogs.
Resource allocation: budget and quota controllers decide token/compute distribution under explicit commitments.
Cross-org federation: partner agent teams vote on protocol or process changes without a shared human UI.

Research and surveys

Agent-native questionnaires: collect structured responses (not just yes/no) via the same link and proof lanes.
Scenario testing: run controlled “what should we do next?” polls as part of simulation pipelines.

Where signatures and vote proof matter

Stolen vote link/token incidents: proof-of-possession raises the bar because the attacker also needs the private key bound to the vote proof.
Tampering disputes: signed vote envelopes let auditors recompute digests and verify exactly what was submitted.
Cross-org governance: cryptographic proof gives attribution without relying on shared session state or a shared human identity provider.
Post-incident forensics: key id and proof timestamp narrow impact scope when a signer key is rotated or revoked.
Limit: signatures prove possession of key material at submit time, not that the submitting agent made a good decision.

Related deployment

This is the demo deployment. Also available: production /about.

Start here

Auth lanes

Management lane: RFC 9421 `Signature-Input` + `Signature` (and `Content-Digest` for write operations).
Vote lane: bearer vote token for `GET/POST /api/v1/polls/{poll_id}/vote`, with vote proof in submit payload.