Skip to main content
Glama

land_deeds_search

Search public land deeds by player, tract ID, or region number to retrieve deeds, worksite, and staking details for analysis.

Instructions

Search public land deeds by player or place (tract_id or region_number); a bare search is refused. A successful limited response is {status, data}, where data is an object carrying deeds, worksite_details and staking_details arrays. The catalogue declares those arrays as arrays of objects, and declares deed_uid as a string ID on each row; use that common deed_uid to join the three arrays. The deeds rows carry the public land-deed fields declared for this route. The worksite_details and staking_details rows carry the fields declared for those arrays, including staking_details[].total_work_per_hour, the per-deed total that a caller would rank deeds by; the response also carries a separate per-hour rate, worksite_details[].work_per_hour_per_one_pp, and this server does not relate the two; what it counts is not stated by the response and is not claimed here. total_work_per_hour is a JSON number, not a string, and this server returns it unchanged; it does not convert, round, rank, sort, sum or compare it, and a change in that wire type would be reported as a malformed response rather than converted silently. A zero total_work_per_hour was observed on deeds whose is_powered value was false, on one page of one account on one day (library/observations/land-deeds-search-details-2026-09-07.md); that observation does not establish that zero proves a deed is unpowered, what the figure counts beyond the field name, or what any unobserved value means. An empty result is a successful upstream answer, not an error, and establishes only that this response carried no rows; it does not establish that an account, place or deed does not exist, that no other matches exist, or that the response is complete. The limited form of this search has object-shaped data rather than an array, so this server's 100-row bound does not apply to that response. The only server result bound that applies to that response is the 256 KB serialized-result limit, and that limit is all-or-nothing. An oversized limited response returns status alone with the deeds, worksite_details and staking_details arrays dropped; the text says "This single record is too large to return within the 256 KB result limit." Request a smaller limit; retrying the same call will not return partial data. Paging probes recorded for this route were offset=0, offset=5, limit=10000, three calls omitting all parameters, and orderBy=desc: offset=0 returned zero rows; offset=5 returned the first four rows of the omitted-offset response; limit=10000 returned 10000 rows; the three omitted-parameter calls returned zero bytes; and orderBy=desc returned an empty data array. No total or has-more field was observed. No offset value tried reached later rows than the omitted-offset response; narrow the player, tract_id or region_number request instead. The observed ordered probe with orderBy=desc returned an empty array (measured 2026-09-06), and this server's contract currently accepts that response. A non-empty ordered response would be reported as malformed rather than returned. Because the observed ordered response was empty, no row bound or truncation is described for that form. Paging probes recorded for this route were offset=0, offset=5, limit=10000, three calls omitting all parameters, and orderBy=desc: offset=0 returned zero rows; offset=5 returned the first four rows of the omitted-offset response; limit=10000 returned 10000 rows; the three omitted-parameter calls returned zero bytes; and orderBy=desc returned an empty data array. No total or has-more field was observed. No offset value tried reached later rows than the omitted-offset response; narrow the player, tract_id or region_number request instead. This server makes one logical upstream request and reports what that request returned; it does not claim to analyse, rank, sort, sum or compare the returned deeds or detail rows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitYes
offsetNo
playerNo
orderByNo
tract_idNo
region_numberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.0.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations at all, the description carries the full burden of behavioral disclosure and does so extensively: the object-shaped response with three joinable arrays, the all-or-nothing 256 KB limit, empty-result semantics, observed paging probe outcomes, and explicit guarantees that total_work_per_hour is not converted, rounded, ranked, sorted, summed, or compared. It even scopes the single zero-value observation and states what it does not establish. This is far beyond anything annotations could have supplied.

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

Conciseness2/5

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

The description is front-loaded with the core purpose, but it is very long and the entire paging-probes paragraph ('Paging probes recorded for this route were offset=0, offset=5, limit=10000...') is repeated verbatim nearly in full. That duplication is a clear structural defect and shows not every sentence earns its place.

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?

Despite having no output schema and no annotations, the description covers response structure, row-joining keys, type guarantees, failure modes, size limits, and paging behavior, and it explicitly scopes what observed cases do not imply. For a six-parameter search tool with this complexity, nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, and the description compensates for all six parameters: player/tract_id/region_number as the required search dimensions, limit (256 KB cap and 'request a smaller limit'), offset (probe results showing no later-row access), and orderBy (observed desc returns an empty array). It also surfaces the important mismatch that a bare search is refused even though the schema marks only limit as required. This gives an agent everything needed to choose parameter values correctly.

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?

The opening sentence states a specific verb, resource, and scope: 'Search public land deeds by player or place (tract_id or region_number); a bare search is refused.' This clearly identifies what the tool does and adds the refusal condition. It does not explicitly name sibling tools such as land_deed_by_uid or land_deeds_owned, so differentiation relies on the declared search dimensions rather than direct comparison.

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?

The description gives clear usage context: a bare search is refused, so one of player, tract_id, or region_number must be supplied, and it advises callers to 'narrow the player, tract_id or region_number request instead' of relying on offsets. It also instructs users to 'Request a smaller limit' when a response is oversized. However, it never names alternative sibling tools or exclusion conditions, so it stops short of a full when/not-and-alternatives statement.

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