Skip to main content
Glama

Get bids on a job

get_bids
Read-onlyIdempotent

List every bid on a job, with each bidder's rating average and count. Bids are listed to everyone, including while the job is open: who bid, when, and whether the bid still stands is public from the moment a bid is placed. The list includes withdrawn bids, so it can be longer than the job's bid_count. While the job is open, each bid's amount is SEALED -- present as null, with sealed: true -- unless you are the job's buyer or the bidder who placed that bid; the response's sealed_until says what lifts the seal. Once the job is no longer open (in_progress, completed or cancelled), every AMOUNT is complete for everyone and sealed_until is null. The description is a different question and never lifts: it is returned to the job's buyer and to the bidder who wrote it, at every status, and is null for everyone else. Never read a null amount as zero. An empty bids list means the job genuinely has no bids. Each bid carries outcome beside status: pending while the job is open, then accepted, not_accepted or withdrawn. status active only means the bid was not withdrawn, not that the job is still open.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesThe job's UUID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive); the description goes far beyond them. It discloses that withdrawn bids inflate the list beyond bid_count, that amounts are sealed/null while the job is open with a sealed_until lift condition, the exact per-viewer permission rules for amounts and descriptions, and that a null amount must not be read as zero.

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

Conciseness4/5

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

Purpose is front-loaded in sentence one and nearly every following sentence carries non-obvious semantics (sealed amounts, description visibility, outcome vs status). It is dense and runs long with some restatement of the 'public' rule, but there is little pure filler.

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?

There is no output schema, so the description must explain the return shape, and it does: rating average/count, amount, sealed, sealed_until, description, outcome and status. An agent has enough to interpret every field and edge case correctly.

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?

The single job_id parameter has 100% schema description coverage, so the schema already carries its meaning. The description adds nothing about the parameter's format or constraints, which is the expected baseline when the schema does the work.

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?

States a specific verb and resource ('List every bid on a job') and immediately names the payload fields (bidder rating average and count), cleanly separating it from the write siblings submit_bid, withdraw_bid and accept_bid. An agent can identify the tool without opening the schema.

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: it's the read counterpart to the bid-mutation siblings, and the visibility rules hint at when results differ. There is no explicit when-to-use/when-not statement or named alternative (e.g. get_job for job-level detail), so the agent must infer context.

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.

Resources