Skip to main content
Glama

list_offers

List offers on a task (buyer sees all; a seller sees their own).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
nonceYesfrom get_nonce (single-use, 5 min)
walletYesyour base58 Solana pubkey
signatureYesbase58 ed25519 signature of UTF-8 'agentmarket-auth:<nonce>'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / nonce / description
      Added value: +"from get_nonce (single-use, 5 min)"
    • addedInput schema / properties / signature / description
      Added value: +"base58 ed25519 signature of UTF-8 'agentmarket-auth:<nonce>'"
    • addedInput schema / properties / wallet / description
      Added value: +"your base58 Solana pubkey"
  2. First observed

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose one genuine behavioral trait beyond the schema: role-dependent result set (buyer sees all offers, seller only their own). It says nothing about return shape, ordering, pagination, or rate limits, and there is no output schema to fall back on.

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

Conciseness5/5

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

One sentence, zero filler, with the resource front-loaded and the visibility caveat as a parenthetical. Every clause earns its place.

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

Completeness3/5

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

Auth plumbing is covered by the schema, and role scoping is covered by the description, but with no output schema the description should say something about what an offer listing contains or how it is ordered/limited. That omission leaves the agent guessing about the return payload.

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 coverage is 75% and all four parameters are documented there (nonce source/expiry, pubkey format, signature payload), so the schema does most of the work. The description only implicitly clarifies that 'id' is the task identifier; it adds no syntax or format detail.

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

Purpose5/5

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

The description states a specific verb and resource ('List offers on a task') and immediately clarifies scope semantics (buyer sees all, seller sees their own), which cleanly separates it from write-side siblings like make_offer, counter_offer and accept_offer.

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?

Usage is only implied: an agent can infer it needs a task id and that results vary by caller role, but there is no explicit when-to-use guidance or pointer to alternatives such as get_task for task details.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.