land_power_core_grouped

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

No annotations exist, so the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals one logical GET, a possible additional reference-resolution GET with a hard two-request limit, no auto-continuation, local truncation at 100 rows and 256 KiB, refusal of oversized records, and the point-in-time nature of the data. This is far more than the basic read-only behavior that might otherwise be assumed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with its core purpose critically. It contains dense, useful behavioral detail, but it also has redundancy: 'One bounded page; no automatic continuation' is later repeated as 'Does not auto-fetch continuation pages.' A missing period and vague statements like 'Required inputs reflect tool policy as well as measured upstream requirements' make the text feel less polished than it should be.

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

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

Considering the tool's complexityhol, no annotations, and no output schema, the description is remarkably complete. It covers request limits, truncation behavior, reference resolution, return-field hints, and data-freshness caveats. It stops short of perfect completeness because it does not fully describe the expected response shape or clarify the semantics of offset/order_by parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description must compensate, but it only explains a subset of parameters. It correctly states that exactly one plot_id (numeric or display label) or deed_uid must be supplied and that original UID spelling is accepted. However, the five required parameters player, offset, limit, order_by, and order_by_asc receive almost no semantic explanation beyond schema types, and optional fields like item_detail_id and name are not described.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Read grouped available Power Core item counts for an explicit player and deed.' It also states the restricted stake type, STK-LND-PCRched. However, it does not explicitly differentiate itself from the sibling tool land_power_core_available, so it falls just short of full clarity.

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

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

The description gives context for use: it targets grouped Power Core counts, is restricted to a verified stake type, and explicitly says no staking or bulk stake-change is performed. It also warns that availability is point-in-time and not a guarantee for later actions. Yet it never names an alternative tool or states when this tool should be preferred over a sibling, so usage guidance remains implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.