Skip to main content
Glama
subimpact

NimBooks

by subimpact
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Staking rewards

get_rewards
Read-onlyIdempotent

Retrieve staking rewards for a Nimiq address over a date window, with totals, reward days, per-pool breakdown, and trailing 30-day yield. Read-only; restaking pools only.

Instructions

Staking rewards for an address over a window: the total (Luna and NIM), the reward days, the first and last reward date, and the breakdown per paying pool, plus an actual yield over the trailing 30 days measured against the current active stake and the current validator's estimate for comparison. Read-only, never signs and never sends. Important: only restaking (compounding) pools show up in this data; a direct-payout pool's rewards arrive as ordinary incoming transactions and are found with list_transactions instead. The public rewards data starts January 2025, so earlier asks come back empty, and it can lag by a day. A year Nimiq Watch did not answer is named in the answer, never silently dropped.

Input Schema

NameRequiredDescriptionDefault
sinceNoStart of the window, YYYY-MM-DD or ISO 8601 (UTC). Default: the start of the public rewards data.
untilNoEnd of the window, YYYY-MM-DD or ISO 8601 (UTC). Default: now.
addressNoNimiq address (NQ form, spaced or flat, or 40 hex characters). Optional; defaults to the server’s configured address.
includeDaysNoInclude the per-day reward rows, newest first, at most 400. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

While annotations cover safety hints, the description provides deep operational behavior: data limitation ('only restaking pools'), data start date ('January 2025'), potential delays ('can lag by a day'), and data quality ('naming unanswered validators'). This significantly enhances the agent's operational awareness.

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 description is highly dense and lengthy, prioritizing information over brevity. While every sentence is packed with value, its sheer volume prevents a higher score for structure and conciseness.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex nature of staking data, the description is exhaustively complete. It handles edge cases, data limitations, expected format (total vs. per-day), and naming conventions for missing data, leaving no high-level ambiguity.

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?

The schema coverage is 100%, setting a baseline of 3. The description elevates this by defining the scope of the data retrieved (Luna and NIM, breakdown per pool) and how the time window functions, adding necessary context to the abstract parameters.

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 purpose is extremely clear: calculating staking rewards for an address over a specified time window. It goes beyond just stating the resource by specifying the types of data returned (total, breakdown, yield) and directly addresses the 'why' of the tool.

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

Usage Guidelines5/5

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

It provides critical usage instructions regarding alternatives. Specifically, it tells the user that 'direct-payout pool' rewards are *not* found here, but must instead be found using `list_transactions`, offering perfect guidance on when to use this tool versus others.

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