Agoranome seller tools

Research brief, by the chapter

research_brief

Read-only

Not answering yet: brief=monthly answers from 1 Dec 2026. Until then, such a call is refused before any payment. One chapter of a research brief on the x402 market, in Markdown with every table also as JSON: a category (demand, prices, survival, rivals, proof), a launch at a price (the gap, the price, the odds, rivals near the price, proof at the price), a pay-to address (its listings, its categories), or Agoranome Monthly (seller survival, buyer depth, openings, the Fair Offer index, prices, what moves buyer agents, adoption, the agent registry). Each brief's contents are free. Name the brief and its chapter: category needs category; launch needs category and price (method optional); address needs address; monthly needs edition. Price: brief=category $0.50; brief=launch $1.00; brief=address $0.25; brief=monthly $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": {
      "brief": "<brief>",
      "chapter": "<chapter>"
    },
    "name": "research_brief"
  }
}

Input Schema

Name	Required	Description
`brief`	Yes	Which brief: category ($0.50 a chapter), launch ($1.00 a chapter), address ($0.25 a chapter), monthly ($1.00 a chapter)
`price`	No	The price per call in USD: launch brief
`method`	No	Optional: GET or POST, launch brief
`address`	No	The pay-to address on Base: address brief
`chapter`	Yes	Which chapter of the brief: category: demand, prices, survival, rivals, proof. launch: gap, price, odds, rivals, proof. address: listings, categories. monthly: sellers, buyers, openings, fair_offer, prices, agents, adoption, registry.
`edition`	No	The edition's month, as 2026-11: monthly
`category`	No	The category: category and launch briefs
`kyapay-token`	No	A 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.

AddedNov 9, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the full economic and failure profile: per-brief prices in USDC, that the 402 response states the single price for the requested arguments, that x402 payment is settled inside the call, that Skyfire pay or kya-pay tokens are an alternative via header or argument, and that failed calls are not charged. It also flags the future-dated monthly refusal occurring before any payment — exactly the kind of context annotations cannot carry.

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

Conciseness3/5

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

Every clause carries real information, but it is delivered as long run-on sentences with nested parentheses that are hard to parse, and it front-loads a temporal caveat ('Not answering yet') before stating what the tool does. Restructuring into a purpose sentence followed by availability, inputs, and payment would cost nothing and read far better.

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?

For an 8-parameter paid tool with no output schema, the description covers argument dependencies, price per brief, payment mechanisms, availability, and return format (Markdown with tables mirrored as JSON). The only gap is comparison with sibling tools serving similar research questions, which matters given the crowded sibling list.

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% and the schema already documents the brief/chapter/price/method/address/edition/category mappings, so the description largely restates structured data (including the same chapter lists). Its marginal additions are the optionality of method and the per-brief price table, which the schema also carries. Baseline 3 is appropriate.

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 concretely — one chapter of a research brief on the x402 market — and enumerates the four brief types with their chapter sets, so an agent knows exactly what is being fetched. It falls short of a 5 because the purpose sentence is buried after an availability caveat and delivery-format clause, and it never distinguishes this tool from topic-adjacent siblings like demand_gaps, price_position, or check_fair_offer.

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?

Usage conditions are stated explicitly: which arguments each brief requires (category needs category; launch needs category and price; address needs address; monthly needs edition), plus a hard availability window — monthly is refused before 1 Dec 2026 with no charge. What's missing is routing guidance versus the many sibling research tools that cover overlapping ground.

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 tools Inspect

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.