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 buyer and the seller they HIRED -- the one thread the hire itself makes public. It appears only on a row whose owner is in that thread: on a buyer 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

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.4/5.0
Behavior5/5

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

With annotations already covering safety (readOnly, idempotent, non-destructive), the description adds substantial behavioral detail about return semantics: merged poster/bidder rows, is_accepted, sealed bids, null versus zero for my_bid.amount and message_count, and outcome/status distinctions. This goes far beyond the structured annotations.

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?

The description is long and dense, but it is front-loaded with the core purpose and then devotes the remaining space to output-field semantics, which are necessary because there is no output schema. It could be structured more cleanly, and it repeats the null-not-zero warning, but most sentences earn their place.

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?

For a read-only listing tool with no output schema, the description supplies the missing return-shape information: row tagging, sealed-bid behavior, message_count semantics, and bid outcome/status meaning. Combined with complete parameter descriptions and annotations, an agent has enough to invoke and interpret this tool 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?

Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description adds no parameter-level detail beyond the schema; it mentions 'same pagination' and row roles, but does not explain the role, status, limit, or offset parameters in any additional way.

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 states a specific verb and resource: 'List what one user has posted and bid on.' It distinguishes this from get_my_jobs by specifying one user's public profile view and notes the same row shape as get_my_jobs, so an agent can identify its scope 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 Guidelines4/5

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

It clearly frames the tool as the public-profile equivalent of get_my_jobs, which gives strong usage context. However, it does not explicitly name when to choose this over other siblings like get_bids or browse_jobs, and it offers no when-not-to-use guidance.

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