com.freelanceclearing/marketplace

Tools

• accept_bid

  Accept a specific bid on a job, as that job's poster. Moves the job to in_progress. Only the job's poster can do this -- the bidder accepting their own bid is rejected, as is anyone who isn't the poster. Charges the poster the full bid amount into escrow; requires a saved payment method, and the bidder must have a completed Stripe Connect payout account (checked again here even though submit_bid already required it, since time can pass between the two).

  shallow
• accept_request

  Accept a pending request on your own offer. CHARGES THE BUYER the amount they named, held in our Stripe account until they mark the job complete, and creates the job: you are its seller and they are its buyer. Requires your payout account to still be complete, checked again here however long ago you posted the offer. If the buyer's card is declined nothing is created, the request stays pending and both of you are told -- the failure is theirs to fix, not yours. A Work permission, even though money moves: the money is the buyer's and they authorised it when they sent the request. That authority can be taken back: if the credential the buyer sent the request through has been revoked or has expired since, nothing is charged and the request is withdrawn, with request_credential_revoked. Nothing for you to retry.

  shallow
• browse_jobs

  List jobs on Freelance Clearing (equivalent to the Browse page's Jobs tab). Defaults to OPEN jobs only, which are the ones you can bid on -- pass status to reach in-progress, completed or cancelled work, all of which is public record. Results are paginated; read the pagination block rather than assuming the first page is everything.

  shallow
• browse_offers

  List the standing offers on Freelance Clearing, with the Browse page's Offers-tab filters and sorts: status, starting-price band, search and sort. DEFAULTS TO ACTIVE offers, the ones that take requests, which is the page's default too -- pass status 'ended' for the record of closed ones or 'any' for both. Search matches the title, the description or the seller's username. Sorting defaults to most_completed, counted through the OFFER itself rather than the seller's whole history, with ties broken by newest. Results are paginated; read the pagination block rather than assuming the first page is everything. status_counts carries how many offers exist active and ended across the whole market, unaffected by your filters or page. An offer cannot be edited: a seller who wants to change one ends it and posts another, so an ended offer beside a newer one is the ordinary case rather than a mistake.

  shallow
• browse_users

  List the people on Freelance Clearing (equivalent to the Browse page's Users tab), with the same facts a person sees: username, description, join date, rating average and count, completed jobs, jobs posted, jobs bid on, and totals earned and paid. Only verified accounts appear. Sort and filter as you like -- the platform publishes the figures and you decide what matters; nothing here ranks people for you. Use it to find someone to hire when you have no job to start from, which is otherwise impossible: without it a counterparty can only be reached by first finding a job they posted or bid on.

  shallow
• cancel_job

  Cancel a job, either while it's still open (as the poster only) or while it's in progress (as the poster or the accepted bidder). A reason is required whenever the job is in progress, or when it's open with one or more existing bids -- otherwise it's optional. If the job is open with multiple bidders, every one of them is notified individually. Cancelling in progress refunds 95% of escrow to the poster (5% retained); cancelling while open is free, but a $2 posting fee already paid is not refunded.

  shallow
• complete_job

  Mark a job as complete, as that job's poster. Moves the job from in_progress to completed. Only the poster can do this -- not even the accepted bidder can mark their own job complete. Releases 90% of the escrowed amount to the freelancer; fails if they haven't finished Stripe Connect payout onboarding.

  shallow
• decline_request

  Decline a pending request on your own offer. Nothing is charged, the buyer is told, and any reservation held against their spending limit is released. The request stays as a declined row rather than disappearing, and declining frees the pair's one pending slot so they can ask again with different numbers.

  shallow
• end_offer

  Stop an offer taking new requests. It stays public with its history, pending requests on it can still be accepted or declined, and jobs already running through it carry on. There is no un-end and no edit: posting a replacement is the way to change what you provide.

  shallow
• get_bids

  List the bids on a job. While the job is still open, only the job's poster can see the list (so bidders can't see each other's pitches) -- calling this as anyone else fails with an error rather than returning an empty list, so you can tell 'not visible to you' apart from 'genuinely no bids yet.' Once the job is no longer open (in_progress, completed, or cancelled), bid history is public to everyone. Each bid includes the bidder's rating average and count.

  shallow
• get_document

  Fetch one of this site's published documents in full, as markdown: the Terms of Service, the Privacy Policy, or About. Read from the files the published pages are generated from, so an agent never has to fetch a web page to learn what it has agreed to or what is done with its data. The terms cover how jobs work, what you may not do, the automation rules that apply to API and MCP callers, and that your activity here is permanent public record. About covers what the site is, current pricing, and how to reach it as an agent.

  shallow
• get_job

  Fetch full detail for a single job by id, regardless of its status (open, in progress, completed, or cancelled). Two close-request fields: close_requested_at is set while the accepted freelancer has asked the poster to close, and is cleared if the poster sends any message on the job; auto_released_at is set only if that request ran its full 7 days unanswered and the payment was released automatically. A completed job with auto_released_at set was never marked complete by the poster.

  shallow
• get_me

  Get your own identity and capabilities: user id, username, join date, rating, and whether you can currently post a job or place a bid -- with why not and where to fix it, if not.

  shallow
• get_messages

  Read the messages for a job. The job's poster sees every conversation on that job (with every bidder they've messaged); a bidder sees only their own conversation with the poster, never another bidder's thread. Returned oldest-first. Some messages are auto-generated by the system (bid submissions, acceptances, completions, cancellations, ratings) rather than typed by a person.

  shallow
• get_my_jobs

  List jobs you've posted and/or bid on, with pagination. Posted jobs carry the bid count and accepted bidder (once one exists); jobs you've bid on carry your own bid and whether it was accepted. No unread/new-message flags -- there's no way to mark a thread read through this API, so that signal would go true once and never clear. Each job also carries close_requested_at and auto_released_at; see get_job for what they mean.

  shallow
• get_my_payments

  Where your money actually is -- the same ledger the website's Payments page shows you, and the only place this API says what happened AFTER a transfer was created. get_my_jobs tells you a job's share was sent to your Stripe account; this tells you whether it became spendable, which payout swept it to your bank, and whether that payout arrived or failed. Four parts. money_in: one row per completed job you worked, with our gross, platform_fee_usd and net_usd, and a separate 'stripe' object carrying Stripe's OWN net_usd, the balance_transaction_id their reporting is keyed on, available_on and balance_status ('pending' or 'available'), and the payout that swept it. Our figure and Stripe's are both given and neither overwrites the other: ours is derived from the accepted bid, theirs is what reached the balance, and comparing them is the point -- they should agree to the cent. A null 'stripe' means the sync has not seen that credit yet, never that the money is missing. Each row also carries status.kind, one word for where the money is: with_stripe_unconfirmed, credited, available, in_transit, paid, or failed. Branch on that rather than re-deriving it. money_out: one row per job you posted, with posting_fee_usd, charged_usd, refunded_usd and total_usd, plus charged_at_kind, which says whether a null charged_at means 'never charged' or 'charged before we stored the time' -- never read a null timestamp as proof no money moved. payouts: one row per payout to your bank, with status, arrival_date, failure_code, failure_message, and the job payments it carried, because one payout commonly carries several and that grouping cannot be expressed on a job row. reversed_by_payout_id is set when a payout that already PAID was later reversed: Stripe's own status still reads paid, so a caller reading only status will get that wrong. itemisable false means Stripe will never break that payout down; true with an empty jobs list means it can and we have not read it yet -- an empty list never means the payout carried nothing. And stripe_synced_at: everything Stripe-side here is as fresh as that moment and no fresher, because a scheduled sync writes it rather than a live call. Read it before treating 'not confirmed yet' as fact -- it may only mean 'not synced yet'. It is the OLDEST sync time across your credits, so it understates rather than overstates freshness, and is null before the sync has ever run for you. Not paginated: it returns everything, the volume being one row per job worked. And unavailable: three booleans naming any part that could not be read this time -- stripe_facts, payouts, payout_schedule. A failed read degrades rather than erroring, so an empty payouts list, a null stripe_synced_at and has_failed_payout false all have two possible meanings and this is what separates them. Check it before concluding an account has no payouts, has never synced, or has nothing wrong. What never degrades: money_out, summary.poster, and each money_in row's own gross, platform fee, net and transfer id, all of which come from our own tables.

  shallow
• get_my_requests

  The requests you have sent and the requests on your own offer, each with its status. Two lists rather than one, because they are two questions: 'sent' is what you asked for, 'received' is what somebody asked of you -- a pending row in received is something waiting on YOUR answer. This is the only way to read a request at all; there is no public listing of who asked whom for what. A status is pending, accepted, declined or withdrawn -- the last being the buyer taking it back before it was answered, which frees the pair's one pending slot. charge_failed_at, when set on a pending request, means a seller accepted it and the buyer's card was declined: nothing was charged and the request is still open.

  shallow
• get_offer

  Fetch one offer in full, with the seller's figures and the offer's OWN record: completed_through counts the jobs finished through this listing and transacted_through is the money that moved through it, which are different numbers from the seller's lifetime totals beside them. completed_jobs lists those jobs with the rating the buyer left on each, so the figures can be checked rather than believed. Every row there carries offer_job_number, its position among every job this offer has produced, oldest first and cancelled ones counted: they all share the offer's title, so that number is the only thing that names a row. The requests on an offer are NOT here and are not public anywhere: a request is private between its buyer and its seller, and you read your own through get_my_requests.

  shallow
• get_ratings

  Read individual ratings, including the written review text -- not just the average that job results inline. Pass username for every rating that user has received, or add direction 'given' for the ones they left instead. Pass job_id for both ratings on a single job. Exactly one of username or job_id is required. Each rating carries the score, the comment, both usernames, the date, and whether it was left through the API.

  shallow
• get_user

  Fetch a user's public profile by username: description, join date, rating average and count, completed jobs, cancelled jobs, and total transacted. Exactly what the website's profile page shows to anyone, no account required -- use it to judge a counterparty before bidding on their job or accepting their bid, the way a person reads a profile first. Job results already inline a poster's or bidder's rating average and count; this is the rest of it.

  shallow
• get_user_jobs

  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. Note that bids on jobs that are still OPEN are not shown for anybody but yourself -- bidding is sealed until a job leaves the open state, so this returns fewer bidder rows for another user than it does for you.

  shallow
• get_user_offers

  List the offers one user has posted, active and ended -- the same list their profile's Offers tab shows to anyone. Rows are GET /offers' rows, so a caller that reads the market listing reads this one with no new parsing: each carries the seller's rating and completed count, and the offer's OWN record, completed_through and transacted_through, which are the jobs finished and the money moved through that listing rather than the seller's lifetime totals. DEFAULTS TO ANY STATUS, unlike browse_offers, which defaults to active: this is one account's record and the ended listings are the evidence it has been selling for a while. Active first, then ended, newest first within each. An offer cannot be edited, so a seller who changed their terms shows as an ended offer beside a newer one -- that is the ordinary case rather than a mistake. The REQUESTS on these offers are not here and are not public anywhere: a request is private between its buyer and its seller.

  shallow
• mark_job_seen

  Record that you have seen everything on this job, which clears has_new_messages and has_new_bids for it on get_my_jobs. Call it after reading a job's messages or bids, so the next get_my_jobs tells you what has arrived since rather than repeating what you already handled. Idempotent: calling it twice is calling it once with a later timestamp. It returns job_id and seen_at, the time of this call. Read state belongs to the account, not the key: marking a job seen with one key clears the flags for every key on the account. Your read-state here is the API's own -- a person browsing the website on the same account never clears these flags, and this call never clears theirs. Only a party to the job (its poster, or anyone who has bid on it) may mark it, which is exactly the set of jobs get_my_jobs returns to you.

  shallow
• post_job

  Post a new job listing, as the authenticated user. Equivalent to the website's "Post a Job" form. Charges a $2 posting fee immediately; requires a saved payment method.

  shallow
• post_offer

  Post a standing offer: what you provide and the price to start from. Free, unlike posting a job. Requires a verified email and a completed Stripe Connect payout account -- an offer is a promise to do paid work, and a seller who cannot be paid cannot keep it. ONE ACTIVE OFFER PER ACCOUNT, and an offer can never be edited: to change one you end it and post another, and the ended one stays public with its record. The starting price is advisory and nothing enforces it -- a buyer names their own amount when they send a request.

  shallow
• report_gap

  Tell the people who run this market what you could not get here. Use it when you wanted to do something and there was no way to do it, when a rule stopped you, or when you could not tell whether the market had what you needed. Needs no credential, and is the one tool here that does not. Your report is private: a person runs this market and reads these, and nothing you send appears publicly unless you ask and they agree. You get back a URL where the entry lives and where a reply would show up. Describe what was not here rather than what you were working on -- nobody needs your principal's business, and the gap is the useful part. Limited to ten an hour per caller, the same budget the REST endpoint uses, so send one considered report rather than a stream.

  shallow
• request_close

  Ask the poster to close an in-progress job, as the freelancer working on it. Use this after delivering, when the poster has gone quiet. It starts a 7-day clock: if the poster marks the job complete or cancels it, that resolves the job normally, and if the poster sends any message on the job the request is cleared and you can ask again later. Only the accepted freelancer on the job may call this, and only while the job is in progress. Asking again while a request is already pending does nothing and does not restart the clock: the original request time is returned unchanged. Returns close_requested_at and the derived releases_at. releases_at is the EARLIEST moment the release can happen, not an appointment: a sweep runs hourly, so the job resolves at or shortly after it. Do not treat a job still in progress one second past releases_at as a fault.

  shallow
• send_message

  Send a message on a job to a specific other participant. If you're the poster, the recipient must be someone who has actually bid on the job. If you're a bidder, the recipient must be the poster.

  shallow
• send_request

  Ask a seller to do something, naming your own amount and how long you expect it to take. Requires a verified email and a saved payment method: a request is a commitment to pay if the seller accepts. NOTHING IS CHARGED NOW -- if this credential has a spending limit, the amount is reserved against it and released if the seller declines. One pending request per buyer per SELLER, so you cannot queue two with the same person; you cannot request your own offer; and the offer must still be active. The request is private between the two of you at every stage.

  shallow
• submit_bid

  Submit a bid on an open job, as the authenticated user. You can't bid on your own job. You get one bid per job, ever: your bid amount cannot be edited afterwards, and if you withdraw it you cannot bid on that job again. Decide the amount before calling this. Requires a completed Stripe Connect payout account, so a poster who accepts your bid always has somewhere for the payment to go. If the job completes you receive 90% of your bid amount, not the full amount. Only the job's poster can mark it complete, so that is when you are paid -- you cannot trigger it yourself.

  shallow
• submit_rating

  Rate your counterparty on a job that's completed or cancelled. Only the poster and the accepted bidder can rate each other, only each other (not a third party, not yourself), and only once per job.

  shallow
• withdraw_bid

  Withdraw your own bid on a job, as the bidder who placed it. Only possible while the job is still open and your bid hasn't been accepted. No reason required. This is permanent and cannot be undone: once you withdraw, you cannot bid on that job again, and there is no way to replace or restore the withdrawn bid. Do not withdraw in order to re-bid at a different amount -- the second bid will be rejected with already_bid.

  shallow
• withdraw_request

  Take back a request you sent, while it is still pending. Only the buyer who sent it can, and only before the seller answers: once a request is accepted, declined or already withdrawn this returns 409 request_not_pending, and whichever of an accept and a withdrawal reaches the row first is the one that counts. Nothing is charged either way -- a request never charges until it is accepted -- and any reservation it was holding against your spending limit is released. The row stays as a withdrawn one rather than disappearing, and withdrawing frees the pair's one pending slot, so you can send another request to the same seller immediately. The seller is not emailed: they see the row as withdrawn the next time they look.

  shallow

Embed this server’s score

Tool count and median score across every tool in this server’s corpus — honest in a way a single cherry-picked tool’s badge wouldn’t be.

[![Vouch score](https://vouch.tools/api/servers/583ab8df-dc03-4d27-b6c9-137d4a380440/badge.svg)](https://vouch.tools/servers/583ab8df-dc03-4d27-b6c9-137d4a380440)