Skip to main content
Glama

Get a user's jobs

get_user_jobs
Read-onlyIdempotent

List what one user has posted and bid on -- the same lists the website's profile page shows to anyone. Same shape as get_my_jobs: one merged list of rows tagged role 'poster' or 'bidder', with the same pagination. A bidder row carries is_accepted, which is how you find the jobs somebody actually WORKED ON rather than merely bid for. Every bid is listed, including bids on jobs that are still OPEN. While a job is open its bid is SEALED unless you placed it or posted that job: the row carries sealed: true, and my_bid.amount and message_count are null -- never read them as zero. They become visible once the job leaves the open state. message_count means something narrower here than on get_my_jobs: on your own rows it is every message on the job you are a party to, and here it is only the messages between the job's poster and the freelancer they HIRED -- the one thread the hire itself makes public. It appears only on a row whose owner is in that thread: on a poster row always, and on a bidder row only when that bidder was the one HIRED. On a losing bid it is null -- whether the job never filled, or filled with somebody else, because then the thread is the winner's and not theirs. Null, never zero, in every one of those cases. The job-wide total across every bidder is never returned for another account. A bidder row's my_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
roleNoDefault both. Same values get_my_jobs takes.
limitNoDefault 25, maximum 100.
offsetNoDefault 0.
statusNoDefault any.
usernameYesThe user's public username, not their UUID. Matched exactly, including capitalization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / username / description
      Previous value: -"The user's public username, not their UUID"New value: +"The user's public username, not their UUID. Matched exactly, including capitalization."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses crucial runtime behavior: sealed bids are hidden for third-party viewers, my_bid.amount and message_count are null rather than zero, and message_count has a narrower meaning than in get_my_jobs. It also explains the outcome field lifecycle and the visibility constraints around hired threads, giving an agent a reliable model of what the response contains.

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 every sentence carries load-bearing semantic detail about nulls, sealed bids, and message_count that directly affects how an agent interprets results. It is front-loaded with the one-sentence purpose, and the dense follow-up paragraphs are justified by the complexity of the returned data.

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 no output schema, the description takes full responsibility for explaining return semantics, and it does so exhaustively: merged rows, role tags, pagination compatibility, is_accepted, sealed behavior, null rules, message_count scope, and outcome values. An agent has enough information to call the tool and correctly interpret the response.

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 input schema already documents all five parameters with 100% coverage, so the description does not need to repeat parameter mechanics. It adds useful response-shape context (e.g., row role tags and sealed semantics) but does not materially deepen the meaning of the request parameters themselves, so the baseline of 3 is appropriate.

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 opening sentence states a specific verb ('List') with a clear resource ('what one user has posted and bid on') and public scope, which distinguishes it from get_my_jobs and other sibling tools. It additionally specifies the result shape upfront, leaving no ambiguity about what the tool retrieves.

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 clear this is the public profile view of one user's activity and repeatedly contrasts its semantics with get_my_jobs, which gives strong context for when to use it. It does not explicitly state exclusions such as 'use get_my_jobs for your own account,' but the profile-page/anyone framing and sibling comparison imply the intended usage well.

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