Skip to main content
Glama
aibtcdev
by aibtcdev

atstake_legion_status

Read live voting weight and eligibility for a legion side; check gates before proposing or voting. Defaults to unlocked wallet or any address.

Instructions

Where a legion stands and whether you can act in it right now: your weight, the vault, the rules, and every gate between you and a proposal.

Voting weight IS your share balance on that side, read live from the market. Below the minimum you can neither propose nor vote; buy weight by minting shares with atstake_mint_complete_set.

Read-only. Defaults to the unlocked wallet, which requires one; pass an address to read anyone without unlocking.

Tip: call earning_opportunities to see how to put your assets to work.

Input Schema

NameRequiredDescriptionDefault
sideYesWhich legion: "yes"/"bonded" argues the coins entered a PoX-5 bond, "no"/"idle" argues they did not.
addressNoWhose eligibility to report. Defaults to the unlocked wallet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.77.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden and discloses key behaviors: it is read-only, defaults to the unlocked wallet (which requires unlocking), and an address can be passed to read anyone without unlocking. It also explains that voting weight is the live share balance and that below the minimum you cannot propose or vote. It does not detail the exact return shape, but overall transparency is strong.

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?

Front-loads the core purpose, then layers in the weight gate, read-only behavior, wallet handling, and a helpful tip. Every sentence contributes to understanding; there is no filler.

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?

Given no output schema, the description explains the key concepts an agent needs: weight, vault, rules, gates, and eligibility constraints. It does not list exact return fields, but for a status-check tool this is largely sufficient.

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 baseline is 3. The description adds useful meaning beyond the schema: it clarifies that weight is the share balance on the chosen side, read live from the market, and that passing an address avoids the need to unlock a wallet.

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?

States a specific verb and resource: reports where a legion stands and your eligibility to act, including weight, vault, rules, and gates. It does not explicitly differentiate from sibling status tools like atstake_market_status or legion_status, but the purpose is clear enough for an agent to understand what it returns.

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 context for when to use it: checking your standing and whether you can propose or vote. It also points to atstake_mint_complete_set for buying weight if below minimum, but does not explicitly state when to use other status siblings instead.

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