Skip to main content
Glama
Sign In

Agoranome seller tools

by io.github.Agoranome
OverviewDiscussionsAdmin

Row sets

row_set
Read-only

Rows of an x402 market table, $0.0002 a row: listing history (each Bazaar listing's category, method, latest price, first and last week seen, weeks listed and price changes) or survival cohorts (each week's new listings by category and how many were still listed one to four weeks on). Filter by category, page with offset, JSON or CSV. Row counts are free at /v1/rows/contents. rows picks the most rows sent, and the price. Price: rows=5 $0.001; rows=50 $0.01; rows=500 $0.10; rows=5000 $1.00, in USDC per call, paid with x402 inside the tool call; the 402 states the one price of what the arguments ask for. Or send a Skyfire pay or kya-pay token in the kyapay-token header (or in this tool's kyapay-token argument), and this tool charges that price to it. Failed calls aren't charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rows": "<rows>",
      "set": "<set>"
    },
    "name": "row_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
setYesWhich table. listing_history: Each listing seen in the weekly Bazaar snapshots: host, category, method, latest USD price, first and last week seen, weeks listed, price changes and whether it is listed now. survival_cohorts: Each week's new listings by category, and how many were still listed one to four weeks on.
rowsYesThe most rows to send, which sets the price: 5 for $0.001, 50 for $0.01, 500 for $0.10, 5000 for $1.00
formatNoOptional: json (columns and rows, the default) or csv as well
listedNoOptional, listing history only: listed now, or gone
offsetNoOptional: skip this many rows (the answer gives the next offset)
categoryNoOptional: one category only
kyapay-tokenNoA Skyfire pay or kya-pay token made for Agoranome's service, from a client that can't set the kyapay-token header. Leave it out when paying with x402 or the header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description still adds real value: tiered pricing per call, x402-in-call payment, the alternate Skyfire/kya-pay token path, and that failed calls aren't charged — genuinely useful behavioral context that annotations cannot express.

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?

It is front-loaded but badly overstuffed: pricing appears three times (per-row rate, the rows=5/50/500/5000 ladder, and again the same ladder in prose), and phrases like 'rows picks the most rows sent, and the price' are convoluted. Several sentences do not earn their place.

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

Completeness4/5

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

With no output schema, the description usefully characterizes the returned columns for each set, plus paging behavior and payment paths — enough for an agent to call it correctly. The one gap is the absence of any routing guidance relative to the many sibling tools.

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?

Schema description coverage is 100%, so the baseline is 3. The description largely restates what the schema already says (the set definitions, the rows-to-price mapping, category/offset/format); the pricing tiers are repeated from the schema's own 'rows' description rather than adding new meaning.

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 names the resource (rows of an x402 market table) and enumerates both variants precisely — listing history with its columns, and survival cohorts with weekly new listings and 1-4 week retention. It is clearly a data-retrieval tool, but it never distinguishes itself from near-neighbours like survival_odds or weekly_insights that an agent would also consider.

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

Usage Guidelines3/5

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

It gives filtering (category), paging (offset with the next offset returned), and format guidance, and redirects to /v1/rows/contents for free row counts. What it never states is when to choose this tool over the sibling analytics tools, nor any eligibility/precondition beyond payment mechanics.

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

All Agoranome seller tools toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources