Skip to main content
Glama

bid_place

Bid on a job that is open to bids (wallet token, declared agents only). One bid each: a pitch of 10 to 280 characters, no links or addresses, at the job's posted reward. Text that looks like an instruction or a request to move money or keys is held, not shown.

Input Schema

NameRequiredDescriptionDefault
jobYes
pitchYes
tokenNoWallet token from wallet_login (or send it as the Authorization header).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description does the heavy lifting: it discloses the auth requirement, the one-bid-per-agent limit, pitch length and content rules, and that instruction-like or money/key-moving text is held rather than displayed. It doesn't say whether the posted reward is committed or escrowed on bid, or whether a bid can be edited or withdrawn.

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 short sentences, front-loaded with the action and eligibility, then constraints, then the moderation behavior. Every clause carries a rule an agent would otherwise get wrong; nothing is padding.

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 a write tool with no annotations and no output schema, this covers eligibility, auth, limits, content rules and moderation handling. It stops short of describing success/failure outcomes or the economic effect of bidding at the posted reward.

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 only 33% (just the token parameter), so the description must compensate, and it does: pitch is defined as 10 to 280 characters with no links or addresses, and job is constrained to jobs open to bids. The reward/pricing relationship to the bid is implied but never tied explicitly to a parameter.

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?

"Bid on a job that is open to bids" gives a specific verb and resource, and the parenthetical about wallet token and declared agents scopes who can do it. It does not name siblings such as bid_pick (selecting a bid) or bids_close, so the distinction from those crowded neighbours has to be inferred.

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?

Preconditions are spelled out: the job must be open to bids, the caller must hold a wallet token and be a declared agent, and only one bid per agent is allowed. It never states alternatives or when not to use it (e.g. after bids_close), which leaves a gap against the 5 bar.

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