vote.direct

Exact election price quote

get_price_quote

Read-onlyIdempotent

Exact, current vote.direct pricing for an election: flat rate by voter count (email verification included, SMS on paid elections), optional government-ID and mailed-letter add-ons, promotional pricing status, whether a subscription would beat paying per election, and the price-beat offer (vote.direct beats a lower quote from another provider for the same self-serve online election). Same constants the product bills against.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "voters": "<voters>"
    },
    "name": "get_price_quote"
  }
}

Input Schema

Name	Required	Description
`voters`	Yes	How many voters will be invited
`gov_id_voters`	No	Voters needing assisted government-ID verification (optional)
`mailed_letters`	No	Mailed access letters to send (optional)
`elections_per_year`	No	If provided, adds the yearly total for that many elections of this size

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / elections_per_year / description

Previous value: -"If provided, compares per-election cost against subscriptions"New value: +"If provided, adds the yearly total for that many elections of this size"

First observedSep 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that by noting the quote uses 'the same constants the product bills against' (authoritative rather than illustrative) and by disclosing what is bundled (email verification included, SMS only on paid elections). No rate limits or latency caveats, but the substantive behavior is disclosed.

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?

A single dense sentence that front-loads the core purpose ('Exact, current vote.direct pricing for an election') and then lists the quote components. No filler, though the comma-chain of clauses is heavy and could be broken for scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does enumerate the quote's components (rate, add-on pricing, promotional status, subscription comparison, price-beat offer). What is missing is the shape/units of the response (currency, per-election vs total breakdown), but coverage is otherwise solid for a 4-parameter read tool.

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 baseline is 3, but the description goes further by mapping parameters to outputs: voter count drives the flat rate, gov-ID and mailed letters are add-ons, and elections_per_year triggers the yearly/subscription comparison. That linkage is not in the schema and helps the agent understand why to pass optional params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — exact current vote.direct pricing for an election — and enumerates what the quote covers (flat rate by voter count, add-ons, promo status, subscription comparison, price-beat offer). It is clearly the pricing tool rather than a comparison or listing tool, but it never names or explicitly distinguishes itself from siblings like compare_platforms or get_platform_overview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: call it when you need a price for a given election size. There is no explicit statement of when to prefer it over compare_platforms (multi-platform comparison) or when it is not appropriate, and no prerequisites are given. Adequate but leaves routing to inference.

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

All vote.direct tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?