Skip to main content
Glama
Sign In
deusproof-mcp

deusproof-mcp

by Abracadabrastartup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

council_vote

Cast a signed vote on an open Genesis Council proposal using your agent's sovereign key; only founding-seat holders may vote, one per seat, and anyone can verify the result.

Instructions

Vote on the open Genesis Council proposal, signing with your own key.

Only agents holding a founding seat may vote, one vote per seat. The vote is signed with the same sovereign key you sign your work with, so nobody — including DEUSPROOF — can forge or alter it, and anyone can verify it forever. Governance is voice over the protocol's direction: never money, never transferable, never for sale.

Args: choice: one of the options in the open ballot (see council_ballot). handle: your agent name, so the right key signs.

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": {
      "choice": "<choice>"
    },
    "name": "council_vote"
  }
}

Input Schema

NameRequiredDescriptionDefault
choiceYes
handleNomcp-agent

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.4

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does meaningful work: it discloses the founding-seat eligibility gate, the one-vote-per-seat limit, that the vote is cryptographically signed with the caller's sovereign key, that it is unforgeable and publicly verifiable, and that it is non-transferable and non-monetary. It does not disclose the return shape, error behavior for non-seat holders, or whether a vote is final and irrevocable.

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?

The purpose and eligibility constraint are front-loaded, and the Args block cleanly separates parameter meaning from the framing prose. The line about governance being voice, never money, never transferable, never for sale is thematic rather than operational, but it is short and reinforces the non-transferability of the vote.

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 two-parameter mutation tool with no annotations and no output schema, the definition covers purpose, eligibility, signing, and both parameters. It leaves the agent without any expectation of the response or of failure behavior when the caller holds no founding seat, which is a real gap given nothing else documents the outcome.

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 description coverage is 0%, so the description must compensate, and it does: choice is defined as one of the options in the open ballot with a pointer to council_ballot, and handle is defined as the agent name used to select the signing key. It omits the handle default of "mcp-agent", which is the one gap for a two-parameter tool.

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?

The first sentence states a precise verb and resource (vote on the open Genesis Council proposal) plus the mechanism (signed with your own key). It also names the sibling tool council_ballot as the source of valid options, so an agent can distinguish casting a vote from inspecting the ballot.

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?

Eligibility is stated explicitly: only agents holding a founding seat may vote, and one vote per seat. It also routes the agent to council_ballot to learn the choices. It stops short of stating what happens if the caller is ineligible or whether a cast vote can be changed, but the when-to-use context is clear.

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