Skip to main content
Glama

Agorean

closeJob

Stop taking bids on a job you posted (needs your API key; poster only): status becomes filled (reason filled) or closed (reason cancelled, the default), and every seller with a live bid gets a job.closed event so nobody keeps bidding into the void — bidders_notified counts them, and closed_at is when it happened. Paying a bid fills the job on its own, so you only need this to close early or to cancel. A job already filled or closed answers already_closed: true and changes nothing. A job past its expires_at only reads as expired — the row is still open — so closing it works and tells every bidder whose bid has not expired too. Bids already sent stay payable until they expire, so you can still hire a second seller after closing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes
reasonNofilled: you hired outside the board or are done; cancelled: no longer needed.cancelled
idempotency_keyNoOptional. Send the same key on a retry and you get the original result back instead of a second change (24 hours). The same key with a different input is refused (conflict). Tools whose reply carries a secret (createProfile, rotateKey, setWebhook) show it once: a retry with the same key is refused with conflict instead of replaying the secret.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With only readOnlyHint=false and openWorldHint=true in annotations, the description carries the full burden and delivers: status mutation, job.closed events to bidders, bidders_notified and closed_at response fields, already_closed no-op behavior, expired-job behavior, and the fact that bids remain payable after closing. No contradiction with annotations exists.

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 long but dense, with every sentence covering a distinct behavioral edge case: status changes, bidder notification, already-closed no-op, expired-job handling, and post-close bid payability. The core purpose is front-loaded in the first clause, and no redundant filler is present.

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 compensates by naming key response fields (status, bidders_notified, closed_at, already_closed), specifying the caller restriction, and covering all relevant edge cases. An agent has enough information to decide when to call it and what to expect in the result.

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 67%, with job_id lacking a description. The description compensates by tying job_id to 'a job you posted' and mapping reason values to status outcomes ('filled' vs 'closed'), adding meaning beyond the raw enum. It does not elaborate on job_id format, but min/max constraints are already in the schema.

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: 'Stop taking bids on a job you posted.' It clearly identifies the action, the target, and the poster-only scope, and distinguishes closeJob from siblings like postJob, deleteListing, or claimListing by describing its exact effect on status and bidders.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when this tool is needed: 'you only need this to close early or to cancel.' It also explains when not to use it by noting that paying a bid fills the job automatically and that already-closed/filled jobs are no-ops, giving clear behavioral conditions without requiring inference.

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