Skip to main content
Glama
michaeljfazio

cardano-node-mcp

by michaeljfazio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create Governance Vote

cardano_governance_vote_create
Idempotent

Create a governance vote file for a Cardano governance action by selecting yes/no/abstain and providing one voter key (DRep, SPO, or CC) plus the action ID, index, and output path.

Instructions

Create a governance vote file for a governance action.

Args:

  • governance_action_tx_id (string): Transaction ID of the governance action

  • governance_action_index (number): Index of the governance action in the transaction

  • vote (string): Vote choice: "yes", "no", or "abstain"

  • drep_verification_key_file (string, optional): Path to DRep verification key (for DRep voter)

  • cold_verification_key_file (string, optional): Path to cold verification key (for SPO voter)

  • cc_hot_verification_key_file (string, optional): Path to CC hot verification key (for CC voter)

  • anchor_url (string, optional): Vote rationale anchor URL

  • anchor_data_hash (string, optional): Vote rationale anchor data hash

  • out_file (string): Output path for the vote file

Exactly one voter key file must be provided (DRep, SPO, or CC).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
voteYesVote choice
out_fileYesOutput path for the vote file
anchor_urlNoVote rationale anchor URL
anchor_data_hashNoVote rationale anchor data hash
governance_action_indexYesIndex of the governance action
governance_action_tx_idYesTransaction ID of the governance action
cold_verification_key_fileNoPath to cold verification key (for SPO voter)
drep_verification_key_fileNoPath to DRep verification key (for DRep voter)
cc_hot_verification_key_fileNoPath to CC hot verification key (for CC voter)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description adds one genuine behavioral rule not in the schema: exactly one voter key file must be supplied. It does not clarify whether the vote is submitted on-chain or merely written to disk, which would be useful for a mutation tool.

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

Conciseness2/5

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

The purpose is front-loaded and clear, but the entire 'Args:' block re-lists all nine parameters that are already 100% described in the schema, which is redundant padding. The only non-duplicative line is the voter-key exclusivity rule, so much of the text does not earn its place.

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

Completeness3/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 should ideally explain the return/result, but it does identify the out_file artifact. It covers the required inputs and the voter-key constraint, but omits whether the tool submits anything or the file's downstream role, leaving moderate gaps for a governance mutation 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 per-parameter descriptions are already fully documented (baseline 3). The description adds genuine cross-parameter meaning beyond the schema by stating the mutual exclusivity of the DRep/SPO/CC key files, which the schema does not express.

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?

States a specific verb and resource ('Create a governance vote file') and scopes it to 'a governance action'. This clearly distinguishes it from the sibling set of cardano_governance_action_create_* tools, which create actions rather than votes on them.

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 rather than stated: it presumes a governance action already exists (via governance_action_tx_id/index) and that a voter key is available. The closing rule 'Exactly one voter key file must be provided' gives partial operational guidance, but no explicit when-to-use versus alternatives and no mention of how or where the resulting vote is used.

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

Deploy Server

Other Tools