Skip to main content
Glama

finalize_poll

Finalize a poll by picking the winning time slot from get_results. Locks the poll and notifies participants via email. Passphrase auto-used from create_poll if available.

Instructions

Finalize a poll by picking the winning time slot. Call get_results first to find the best optionId. Uses the passphrase auto-saved from create_poll. If the MCP server was restarted since poll creation, provide the passphrase manually. This locks the poll and notifies participants who provided an email.

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": {
      "pollId": "<pollId>",
      "optionId": "<optionId>"
    },
    "name": "finalize_poll"
  }
}

Input Schema

NameRequiredDescriptionDefault
pollIdYesPoll UUID
optionIdYesWinning time slot option UUID (pick from get_results)
passphraseNoAdmin passphrase (auto-used from create_poll if available)

Implementation Reference

  • Handler logic for finalize_poll: parses pollId, optionId, and optional passphrase; retrieves or uses provided passphrase; gets admin token; calls API to finalize; returns success with poll details.
    case "finalize_poll": {
      const input = z.object({
        pollId: z.string(),
        optionId: z.string(),
        passphrase: z.string().optional(),
      }).parse(args);
    
      const passphrase = input.passphrase || passphraseMap.get(input.pollId);
      if (!passphrase) {
        return JSON.stringify({
          error: "No passphrase available. Provide the passphrase that was returned when the poll was created.",
        });
      }
    
      const adminToken = await client.getAdminToken(input.pollId, passphrase);
      const result = await client.finalize(input.pollId, input.optionId, adminToken);
    
      return JSON.stringify({
        success: true,
        pollId: result.id,
        title: result.title,
        status: result.status,
        finalizedOption: result.finalizedOption,
      }, null, 2);
    }
  • src/index.ts:115-131 (registration)
    MCP server registration of the finalize_poll tool with name, description, Zod schema for arguments, and handler that delegates to handleToolCall.
    server.tool(
      "finalize_poll",
      TOOL_DESCRIPTIONS.finalize_poll,
      {
        pollId: z.string().describe("Poll UUID"),
        optionId: z.string().describe("Winning time slot option UUID (pick from get_results)"),
        passphrase: z.string().optional().describe("Admin passphrase (auto-used from create_poll if available)"),
      },
      async (args) => {
        try {
          const text = await handleToolCall("finalize_poll", args, client, stdioSession());
          return { content: [{ type: "text", text }] };
        } catch (e) {
          return { content: [{ type: "text", text: `Error: ${e instanceof Error ? e.message : String(e)}` }], isError: true };
        }
      },
    );
  • Type definition for the result returned by the finalize API call.
    export interface FinalizeResult {
      id: string;
      title: string;
      status: string;
      finalizedOptionId: string;
      finalizedOption: { id: string; start: string; end: string };
    }
  • Client helper that sends a POST request to the finalize endpoint with optionId and adminToken.
    async finalize(pollId: string, optionId: string, adminToken: string): Promise<FinalizeResult> {
      return this.request<FinalizeResult>("POST", `/api/open/polls/${pollId}/finalize`, { optionId, adminToken });
    }
  • Client helper that exchanges the poll passphrase for an admin token needed to finalize.
    async getAdminToken(pollId: string, passphrase: string): Promise<string> {
      const data = await this.request<{ token: string }>("POST", `/api/open/polls/${pollId}/admin-token`, { passphrase });
      return data.token;
    }

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Discloses important side effects: locks the poll and notifies participants with email. Explains passphrase auto-save behavior and manual fallback. Since no annotations provided, description fully handles behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each serving a distinct purpose: main action, prerequisite, passphrase detail, and side effects. No wasted words; information is front-loaded.

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

Completeness5/5

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

Covers all necessary aspects for a tool with 3 parameters and no output schema: purpose, prerequisite, parameter details, passphrase handling, and consequences. No gaps identified.

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?

Input schema already has 100% description coverage for all three parameters, so baseline is 3. Description adds meaningful context: directs to use get_results for optionId and clarifies passphrase auto-save vs manual provision.

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

Purpose5/5

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

Explicitly states 'Finalize a poll by picking the winning time slot', which clearly conveys the verb and resource. Distinguishes itself from sibling tools like create_poll, get_results, and vote_on_poll by specifying the action of finalizing and referencing get_results.

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

Usage Guidelines4/5

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

Provides clear prerequisite by advising to call get_results first to find the best optionId. Also explains when to manually provide the passphrase (if server restarted). Lacks explicit when-not-to-use, but context is sufficient.

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