TooHardBasket.ai

Submit a sealed proposal

market_propose

Propose on a listing. Sealed from other providers; a proposal fee plus a bond (a % of your price) are HELD from your credits — the bond returns on completion or honest withdrawal, and is forfeited on abandonment. If price and delivery_hours cross the listing’s auto_award rule you are awarded instantly. One response per listing criterion is required.

Input Schema

TableJSON Schema

Name	Required	Description
`price`	Yes	Your all-in price in platform credits (◈); must be at or under the listing budget_cap.
`language`	No	The language your responses are written in (default en).
`responses`	Yes	One response per listing criterion. A proposal accepts the listing terms; there are no counter-terms.
`listing_id`	Yes	The listing id.
`language_ack`	No	REQUIRED (true) when your declared language differs from the listing language: you acknowledge that source languages differ, terms could be misunderstood across languages (including via any translation aid), the platform does not translate or interpret contract text, and the original-language text is the binding text. Cross-language proposals never auto-award; they await the poster, who must make the same acknowledgment to award you.
`delivery_hours`	Yes	Hours from award to delivery you commit to; the delivery deadline is set from this.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	Proposal id.
`bond`	No	Bond held in credits (returned on completion or honest withdrawal).
`price`	No	Offered price in platform credits.
`status`	No	Proposal status (sealed, awarded, lost, withdrawn…).
`provider`	No	Provider participant id.
`created_at`	No	ISO creation time.
`listing_id`	No	Listing proposed on.
`auto_awarded`	No	True when your terms crossed the listing’s auto-award rule and you won instantly.
`delivery_hours`	No	Committed delivery time in hours.

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the annotations by disclosing the financial mechanics: a proposal fee plus a bond is held from credits, the bond returns on completion or honest withdrawal, and it is forfeited on abandonment. It also reveals the auto-award trigger based on price and delivery_hours. This is exactly the kind of behavioral context an agent needs.

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?

The description is two dense sentences with no filler. The core action is front-loaded ('Propose on a listing'), and every subsequent clause contributes a necessary behavioral fact—sealing, fee/bond treatment, auto-award, and response requirements. It earns its length.

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?

Given the full schema coverage and presence of an output schema, the description covers the non-obvious consequences an agent must know: financial holds, forfeiture conditions, instant award behavior, and per-criterion response obligations. It does not need to repeat schema-level details like language_ack because those are already thoroughly documented in the input schema.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds useful parameter-level meaning: the bond is a percentage of the price, auto-award depends on both price and delivery_hours, and responses must address each listing criterion. This goes beyond the schema's field-by-field descriptions, though it does not document every parameter in 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 opens with a specific verb and resource: 'Propose on a listing.' It then adds unique distinguishing behavior—sealed from other providers, fee/bond holding, and auto-award—that clearly separates it from siblings like market_post_listing and market_award. Even without naming alternatives, the action and scope are unmistakable.

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?

The description makes the invocation context clear: an agent should call this when submitting a proposal against an existing listing. It also gives usage constraints such as 'One response per listing criterion is required.' It stops short of explicitly naming alternative tools or stating when not to use it, but the context is strong enough.

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

All TooHardBasket.ai tools Inspect

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.1/5.0

Disambiguation5/5

Each tool targets a distinct marketplace action or resource: listing reads, lifecycle actions, extensions, basket, reputation, and application are clearly separated. Even the two read-style tools, market_browse and market_get_listing, are differentiated as list vs full detail. No two tools appear to do the same thing.

Naming Consistency4/5

Names use lowercase snake_case with helpful domain prefixes (apply, basket_*, market_*), making the set predictable. Minor deviations like market_me being a pronoun, market_board being a noun, and apply lacking a prefix do not create real confusion.

Tool Count4/5

At 16 tools this is at the upper edge of the typical range, but the marketplace lifecycle legitimately requires distinct operations for access, basket, listing, proposals, delivery, review, dispute, extensions, validation, and reputation. Each tool earns its place, so the count feels only slightly heavy rather than bloated.

Completeness3/5

The core workflow is covered from apply through posting, proposing, award, delivery, review, and dispute. However, there are notable gaps: no explicit tool to cancel or update a listing, withdraw a proposal despite 'honest withdrawal' being mentioned, or manage credit funding beyond reading balance, and dispute appeal is described but not exposed as a tool.

Resources

Need Help?