Skip to main content
Glama

conflict_airdrop_distribution

Fetch a player's recorded airdrop distribution for an explicit conflict or ID. Returns distribution details without claiming prizes or recomputing counts.

Instructions

Read a player's recorded airdrop distribution for an explicit id or conflict. The conflict alias also returned conflict metadata, while id returned only distribution. No prizes are claimed; num_prizes is not recomputed. Makes one logical GET request Does not auto-fetch continuation pages. Required inputs reflect tool policy as well as measured upstream requirements. Other declared filters are forwarded as supplied; their effectiveness is not implied by the schema. The distribution list are locally limited to 100 rows and 256 KiB, with truncation reported in text and metadata. Oversized records are refused without partial fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
loreNo
modeNo
playerYes
conflictNo
order_byNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0

TDQS

A3.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so comprehensively: it discloses no prize claiming, no num_prizes recomputation, single GET request without auto-pagination, forwarding of filters without implied effectiveness, local limits (100 rows/256 KiB) with truncation reporting, and refusal of oversized records. This is exemplary transparency.

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 description is dense but every sentence carries essential behavioral or scoping information. It opens with purpose then systematically lists caveats, which is logical and front-loaded. Slight verbosity in the filter-forwarding warning could be trimmed, but no redundancy.

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?

Covers purpose, behavior, and limits well, but does not describe the expected return structure or the meaning of all parameters. With no output schema and no annotations, the agent is left without knowledge of the distribution's fields or the impact of order_by, making it only partially complete for a tool of this complexity.

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?

Adds meaningful distinction between id and conflict parameters, explaining their differing return contents, and warns that other filters are forwarded without guaranteed effectiveness. However, given 0% schema description coverage, it fails to explain the semantics of lore, mode, and order_by, leaving them under-specified.

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 (read) and resource (player's recorded airdrop distribution) and clearly distinguishes two access modes via id or conflict, noting that conflict returns metadata while id returns only distribution. This sharply differentiates it from sibling conflict_* and player_* tools.

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?

Provides no explicit guidance on when to choose this tool over alternatives like conflict_seasons or conflict_players, nor does it state exclusions. The mention of 'explicit id or conflict' implies prerequisite context, but the absence of any when/when-not guidance leaves the agent to infer.

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