Tools for agents: Explicit quorum and approval evaluator

Evaluate participation and approval thresholds over supplied ballots, with missing-voter lists and completion feasibility.

Connect with MCP

{
  "mcpServers": {
    "super-agent-tools": {
      "url": "https://app.getsupers.com/sites/agent-quorum/mcp"
    }
  }
}

Streamable HTTP · No API key · Stateless

Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.

Call `evaluate_quorum`

Stateless evaluation only: this does not request votes, authenticate voters, authorize a handoff, or persist decisions. Supply a nonempty list of unique exact case-sensitive voter IDs and at most one ballot per eligible voter. Unknown or duplicate voters fail, including repeated identical ballots. Approve, reject and abstain all count toward participation; only approve counts toward approvals. Thresholds are explicit integers from 1 through the number of eligible voters; no majority rule is inferred. Satisfied means both thresholds currently hold. Pending means missing voters can still satisfy both by approving. Impossible means even all missing voters approving cannot meet the approval threshold. Feasibility assumes existing ballots remain fixed and missing voters may submit; it is not a prediction. Abstentions are fixed non-approvals under this assumption. There is no veto, deadline, weighting or ballot replacement rule. Voter lists preserve eligible-list order. Inputs and outputs are not evidence of identity or consent.

Input and output schemas

{
  "name": "evaluate_quorum",
  "title": "Explicit quorum and approval evaluator",
  "description": "Tally unique eligible ballots against explicit thresholds and report whether missing ballots could still satisfy both thresholds.",
  "inputSchema": {
    "$defs": {
      "Ballot": {
        "additionalProperties": false,
        "properties": {
          "voter": {
            "title": "Voter",
            "type": "string"
          },
          "vote": {
            "enum": [
              "approve",
              "reject",
              "abstain"
            ],
            "title": "Vote",
            "type": "string"
          }
        },
        "required": [
          "voter",
          "vote"
        ],
        "title": "Ballot",
        "type": "object"
      }
    },
    "properties": {
      "eligible": {
        "items": {
          "type": "string"
        },
        "title": "Eligible",
        "type": "array"
      },
      "ballots": {
        "items": {
          "$ref": "#/$defs/Ballot"
        },
        "title": "Ballots",
        "type": "array"
      },
      "participation_required": {
        "title": "Participation Required",
        "type": "integer"
      },
      "approvals_required": {
        "title": "Approvals Required",
        "type": "integer"
      }
    },
    "required": [
      "eligible",
      "ballots",
      "participation_required",
      "approvals_required"
    ],
    "title": "evaluate_quorumArguments",
    "type": "object"
  },
  "outputSchema": {
    "additionalProperties": true,
    "title": "evaluate_quorumDictOutput",
    "type": "object"
  },
  "icons": null,
  "annotations": {
    "title": null,
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  },
  "meta": null,
  "execution": null
}

Structured result

Run the example to see the actual result.

HTTP alternative

POST https://app.getsupers.com/sites/agent-quorum/call
Content-Type: application/json

{
  "eligible": [
    "builder",
    "reviewer",
    "tester",
    "owner"
  ],
  "ballots": [
    {
      "voter": "builder",
      "vote": "approve"
    },
    {
      "voter": "reviewer",
      "vote": "approve"
    },
    {
      "voter": "tester",
      "vote": "abstain"
    }
  ],
  "participation_required": 3,
  "approvals_required": 3
}

The HTTP and MCP interfaces execute the same implementation. Validation errors are returned explicitly. See the tool notes above for its supported inputs and behavior.

Participation, approval and completion feasibility

Your browser does not support video.

Read the explanation

The supplied example has four eligible voters. Builder and reviewer approve, tester abstains and owner is missing. Participation is three, meeting its threshold three. Approval is only two, below its separate threshold three. Abstain and reject both count toward participation, but only approve counts as approval. Thresholds are explicit integers; the tool infers no majority rule or veto. The example is pending because owner can still approve, bringing approvals from two to the required three. Feasibility assumes existing ballots remain fixed and missing voters may submit. It is not a prediction that the owner will vote yes. If owner approves, both thresholds hold and status becomes satisfied. If owner instead rejects or abstains, all voters participate but only two approve, so completion becomes impossible under that fixed-ballot assumption. IDs are exact and case sensitive. Unknown voters, duplicate eligible IDs or repeated ballots fail, even if repeated ballots are identical. Missing voter lists preserve the eligible-list order. There is no ballot replacement, deadline or weighting rule. The tool evaluates supplied data without requesting votes, authenticating identities, authorizing handoffs or persisting consent. This video follows its published contract; no remote HTTP or MCP execution was requested or verified.

Evaluating Quorum and Approval Feasibility in Multi-Agent Workflows

How does evaluate_quorum determine whether an incomplete ballot set can still satisfy explicit participation and approval thresholds?

The evaluate_quorum tool performs a deterministic, stateless tally over fixed voter lists and submitted ballots. It validates that every ballot comes from a known eligible voter without duplicates, then evaluates two independent constraints: total participation (approvals, rejections, and abstentions combined) and positive approvals. When thresholds are not yet fulfilled, the evaluator checks completion feasibility under the assumption that existing ballots are fixed while any remaining uncast ballots could vote approve.

The evaluator executes pure combinatorial arithmetic over supplied strings; it does not authenticate voter identity, verify cryptographic signatures, prevent sybil attacks, enforce deadlines, or persist state across steps. Feasibility assumes existing votes are monotonic and immutable while uncast ballots could vote approve; it does not model veto power, weighted voting, or dynamic consensus protocols.

Try a worked example

Leaving the default JSON arguments in place (4 eligible voters, 2 approvals from builder and reviewer, 1 abstention from tester, and thresholds of 3 participants and 3 approvals), click 'Run tool'. The call evaluates 3 participants, satisfying the participation threshold (participation_shortfall: 0, quorum_met: true). Because approvals are 2 out of 3 required (approval_shortfall: 1), the approval threshold is not yet met. With 1 voter remaining ('owner'), the maximum possible approvals is 2 + 1 = 3, yielding status 'pending' rather than 'impossible'.

Participation vs. Approval Accounting

In the backend implementation (quorum.py), ballots are partitioned into approve, reject, and abstain categories. The participant count equals the total number of submitted unique eligible ballots. All three vote types satisfy participation_required, but only explicit approve ballots increment the approvals tally toward approvals_required.

Feasibility Calculation Logic