Skip to main content
Glama
michaeljfazio

cardano-node-mcp

by michaeljfazio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create Pool Registration Certificate

cardano_stake_pool_registration_certificate
Idempotent

Generate a Cardano stake pool registration certificate by specifying cold/VRF keys, pledge, cost, margin, owner keys, relays, and metadata.

Instructions

Create a stake pool registration certificate with full pool parameters.

Args:

  • cold_verification_key_file (string): Path to cold verification key file

  • vrf_verification_key_file (string): Path to VRF verification key file

  • pledge (number): Pledge amount in lovelace

  • cost (number): Fixed cost per epoch in lovelace

  • margin (number): Pool margin (0.0 to 1.0)

  • reward_account_verification_key_file (string): Path to reward account verification key

  • pool_owner_verification_key_files (string[]): Paths to pool owner verification keys

  • pool_relay_ipv4 (string[], optional): IPv4 relays in format "IP:port"

  • single_host_pool_relay (string[], optional): DNS relays in format "hostname:port"

  • multi_host_pool_relay (string[], optional): Multi-host DNS relays

  • metadata_url (string, optional): Pool metadata URL

  • metadata_hash (string, optional): Pool metadata hash (hex)

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
costYesFixed cost per epoch in lovelace
marginYesPool margin (0.0 to 1.0)
pledgeYesPledge amount in lovelace
out_fileYesOutput path for the certificate file
metadata_urlNoPool metadata URL
metadata_hashNoPool metadata hash (hex)
pool_relay_ipv4NoIPv4 relays in format "IP:port"
multi_host_pool_relayNoMulti-host DNS relays
single_host_pool_relayNoDNS relays in format "hostname:port"
vrf_verification_key_fileYesPath to VRF verification key file
cold_verification_key_fileYesPath to cold verification key file
pool_owner_verification_key_filesYesPaths to pool owner verification keys
reward_account_verification_key_fileYesPath to reward account verification key

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations declare idempotentHint=true and destructiveHint=false, which tells the agent this is a safe, repeatable write operation. The description adds no behavioral context beyond that – it does not state side effects, overwrite semantics, or whether it requires network access (openWorldHint=false is already in annotations). With annotations covering the safety profile, the description's lack of extra context is acceptable but minimal.

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

Conciseness3/5

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

The first sentence is concise and front-loaded, but the subsequent parameter list is redundant given the schema and makes the description unnecessarily long. The structure is clear but wastes space on information already available in structured form.

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?

For a complex 13-parameter tool with no output schema, the description is adequate but not rich. It could explain the purpose of the certificate, its role in pool registration, or how it is used in subsequent transactions. Annotations cover idempotency and safety, but the agent still lacks context on when and why to use this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 13 parameters. The description lists them again but adds no new semantic meaning beyond what is in the schema (e.g., it does not clarify the distinction between single_host_pool_relay and multi_host_pool_relay or the implications of setting pledge/cost/margin). Baseline 3 is appropriate.

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?

The description states a specific verb (Create) and resource (stake pool registration certificate) and notes it uses 'full pool parameters', which distinguishes it from the sibling retirement certificate. However, it does not explicitly differentiate from related tools like cardano_stake_pool_retirement_certificate or cardano_stake_pool_issue_op_cert beyond the obvious name difference.

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

Usage Guidelines2/5

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

No when-to-use guidance is provided. It does not state prerequisites (e.g., needing a cold key and VRF key), nor does it mention alternatives like the retirement certificate. The agent must infer from the tool name and parameters.

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