Skip to main content
Glama
Zoldenburg-me

Safe-MPC

by Zoldenburg-me
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Cast an on-chain Snapshot X vote from the Safe

snapshot_x_vote

Cast final on-chain For, Against, or Abstain votes as a Safe on Snapshot X proposals via the EthTx authenticator, with automatic strategy resolution and pre-sign simulation.

Instructions

Votes For, Against or Abstain on a Snapshot X (snapshot.box) proposal as the Safe. The Safe calls the space's EthTx authenticator, which forwards Space.vote with the Safe as voter — the path snapshot.box itself uses for smart-contract wallets, since a Safe cannot produce the gasless EIP-712 signature. This is an on-chain transaction: it costs gas and is final, Snapshot X does not allow changing a vote. The Safe's voting strategies are resolved automatically and the vote is simulated from the Safe before anything is signed. Read the proposal with snapshot_x_proposal first.

Input Schema

NameRequiredDescriptionDefault
spaceYesThe Snapshot X space: a space contract address, a prefixed id like "eth:0x594E…", or a full snapshot.box proposal URL (in which case proposalId can be omitted).
choiceYesHow to vote. Maps to the sx-evm Choice values 1, 0 and 2.
reasonNoPublic rationale. Pinned to IPFS and attached to the vote as its metadata URI, which is how snapshot.box shows a reason.
proposalIdNoThe proposal number, e.g. 3. Not needed when the space is a proposal URL.
skipChecksNoBypass the pre-flight checks and simulation, and submit every active strategy. Only for sx-evm forks that break the standard view methods.
metadataUriNoUse this metadata URI (e.g. ipfs://…) instead of pinning the reason. Pass an empty string to vote with no metadata.
authenticatorNoThe space's EthTx authenticator. Defaults to the snapshot.box deployment 0xBA06E6cCb877C332181A6867c05c8b746A21Aed1; only needed for custom spaces.
strategyParamsNoPer-strategy user params, for strategies that need them (a merkle whitelist proof, for instance). Other active strategies use 0x00.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: on-chain, costs gas, final, Snapshot X forbids changing a vote, strategies resolved automatically, and the vote is simulated from the Safe before signing. This tells the agent the irreversibility and pre-flight behavior that the hint flags alone (non-idempotent, non-destructive) cannot convey.

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?

Five tight sentences with no filler; the action, mechanism, and irreversibility warning are front-loaded and the read-first prerequisite closes it.

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?

Covers mechanism, cost, finality, and simulation for an 8-parameter mutation with no output schema. The remaining gap is what happens after submission — whether this executes immediately or becomes a pending Safe transaction needing co-owner confirmation, which the sibling safe_pending_transactions/safe_confirm_transaction tools suggest is relevant.

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 every parameter is already documented, and the description adds only the note that strategies are resolved automatically (relevant to strategyParams) and that skipChecks exists for broken forks. Baseline 3 applies since the schema does the heavy lifting.

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 ('Votes For, Against or Abstain on a Snapshot X proposal as the Safe') and immediately explains the mechanism (EthTx authenticator → Space.vote with the Safe as voter). The gasless EIP-712 contrast distinguishes it from the off-chain sibling snapshot_vote.

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?

Explicitly says to read the proposal with snapshot_x_proposal first, and explains that this is the path for smart-contract wallets because a Safe cannot produce a gasless signature — which implicitly tells the agent when to prefer it over the gasless vote path. It does not name snapshot_vote as the excluded alternative outright.

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