Skip to main content
Glama

Resollo Agent API

by com.resollo

List the authenticated user's own Resollo offers

offers.list
Read-only

Returns the caller's most recent Make-an-Offer / bargaining offers. Pass role: 'buyer' for offers you sent, or role: 'seller' for offers received on your own listings. Optionally filter to a single state (pending / accepted / rejected / countered / buyer_accepted / expired). Each entry has the product, the offered price, the seller's counter price if any, and timestamps. Read-only, no side effects. Requires an 'Authorization: Bearer ' header.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleYesWhose side to list from: 'buyer' returns offers you sent, 'seller' returns offers received on your listings.
limitNoMaximum number of most-recent offers to return (1-50, default 20).
stateNoOptional filter to a single offer state. When omitted, offers in every state are returned.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
offersYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

The description repeats the readOnlyHint annotation by stating 'Read-only, no side effects,' and adds an auth requirement ('Authorization: Bearer <agent api key>') that the schema and annotations do not provide. It also discloses the returned entry fields and most-recent ordering, which is useful behavioral context.

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?

Three sentences with no filler: purpose, parameter guidance, return contents, and side-effect/auth note each earn their place. Important usage information is front-loaded.

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?

With an output schema present and annotations covering read-only behavior, the description covers everything an agent needs: role requirement, optional filters, output shape, ordering, auth, and side-effect safety. No critical operational gap remains.

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 100%, so parameters are already documented. The description restates the role and state semantics and clarifies default behavior, but adds little beyond the schema's own descriptions.

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 opens with a specific verb and resource: 'Returns the caller's most recent Make-an-Offer / bargaining offers,' and clarifies it concerns the caller's own offers. The title and description together distinguish this read operation from sibling mutation tools like offers.make and offers.respond.

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?

It gives explicit invocation guidance: pass role 'buyer' for sent offers or 'seller' for received offers, and optionally filter by state. It does not name alternatives or state when not to use this tool, but the read-vs-mutate distinction across sibling names is clear.

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

All Resollo Agent API toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool is cleanly grouped by resource (marketplace, offers, orders, products, questions, reviews, sellers) and within a group every action is distinct. There is no real overlap between e.g. orders.place, orders.checkoutLink, and orders.status, or between offers.make and offers.respond.

Naming Consistency4/5

Tool names follow a predictable resource.action pattern with lowercase verb-like second segments (offers.list, products.create, questions.ask). Minor deviations exist: orders.checkoutLink uses camelCase and sellers.listings is a noun rather than a verb, but the overall convention remains easy to infer.

Tool Count3/5

18 tools sits in the 16-25 borderline-heavy range. The marketplace scope is broad enough that most tools feel justified, but the count is slightly above the ideal well-scoped band and could be seen as heavy for a single API server.

Completeness3/5

The server covers core marketplace browsing, product draft creation, order placement, offers, questions, and reviews well. However, there are notable lifecycle gaps: products can be created but not updated/deleted/activated via API, orders have no dispatch/confirm/receive actions, and offers have no cancel action, with several operations pushed to the web UI.

Resources