Skip to main content
Glama

rental_bids

Read public SPSP token delegation rental bids, filterable by player, price range, and quantity range. Supports sorting, offset, and limits up to 100.

Instructions

Read public SPSP delegation rental bids with an explicit limit of 1 to 100. Two pages of two transaction IDs matched the first four rows. Quantity bounds worked, including a 10000 exact range. Price filters accepted integer 1 but rejected decimal 0.001 with HTTP 400; values are forwarded without rescaling. A combined player, amount-ascending, maxPrice=1 and quantity-range probe returned only the selected player and in-range quantities. Other combinations remain unmeasured. These are token delegation offers/bids, not card-worker rentals. Quantities, prices and escrow retain their wire string types. Makes one logical GET request and 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 data 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
sortNo
limitYes
orderNo
offsetNo
playerNo
maxPriceNo
minPriceNo
maxQuantityNo
minQuantityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0

TDQS

B3.1/5.0
Behavior5/5

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

With no annotations, the description fully carries behavioral disclosure. It clearly states pagination behavior (one GET, no auto-fetch), local limits (100 rows, 256 KiB), truncation reporting, error handling (HTTP 400 for decimals, oversized records refused), and that filters are forwarded without rescaling. This is exceptionally detailed and goes far beyond typical expectations.

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 long and rambling, mixing a one-sentence purpose with a series of empirical observations from QA testing. It is not front-loaded with actionable information; after the first sentence, an agent must wade through irrelevant probe results. Every sentence should add value, but many here are speculative ('Other combinations remain unmeasured') or redundant with schema constraints.

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

Completeness2/5

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

For a 9-parameter tool with no output schema and no annotations, the description is incomplete. It fails to explain the semantics of most parameters, the response structure, or how to interpret the returned data. While it covers edge cases and size limits, it omits fundamental usage details that an agent would need to call the tool correctly, such as what 'sort' and 'order' accept, what 'player' filters, and how results are shaped.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. However, it only mentions parameters in the context of test probes (e.g., 'player, amount-ascending, maxPrice=1') without explaining what each parameter does or its expected format. It notes that price filters reject decimals, but does not clarify that maxPrice/minPrice should be integers, nor does it describe the meaning of sort, order, offset, or quantity filters.

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 description opens with a clear verb and resource: 'Read public SPSP delegation rental bids.' It distinguishes these from card-worker rentals, but does not differentiate among sibling tools like rental_bids_lowest_price or rental_bids_by_player. The purpose is clear but the text is cluttered with test details that obscure the core functionality.

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?

No explicit guidance on when to use this tool versus alternatives. The description mentions 'not card-worker rentals' but never names sibling tools or conditions for selection. It discusses limitations and unmeasured combinations but does not help an agent decide between rental_bids, rental_offers, or the 'lowest_price' variants.

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