Fiverr

Find freelancers who match a user's project, business, or professional need. Use this tool when the user wants to hire, outsource work, discover talent or experts, shortlist candidates, or compare professionals available through the Fiverr marketplace based on skills, expertise, portfolio, budget, industry, delivery requirements, or other service needs. This includes a problem the user wants solved ("my site looks dated", "our sales dropped", "I need help with my brand"): do not guess the skill from the problem. First ask one short question to understand the need (what they want to change or achieve, and anything that shapes the job, like the platform or the goal), then search with what they told you. Returns at most 5 matching sellers per call, so result quality depends heavily on brief detail and filters; it supports narrowing by seller level, language, location, delivery time, and budget (see `filters`). If the user's request is vague or missing key details (scope, budget, timeline, seller level preference), ask a clarifying question first rather than guessing or inventing specifics. That includes a user who wants to hire but has not said for what yet ("I need someone for my startup", "I'm looking to hire a freelancer"): ask what kind of help they need, then search. USE talk_to_mira INSTEAD when the user asks for help with the hiring itself: writing or scoping a brief, getting quotes, what the work would cost, choosing between options, working out what kind of talent a project needs ("no idea what kind of developer I need"), or whether to outsource at all. AFTER THE FIRST RESULTS in a conversation, end with a short menu of three next steps, one line each: (1) narrow the search with one or two filters the user has not set yet that matter for this job (budget, delivery time, seller level, language or location); (2) ask about any of these sellers: their reviews, services and prices; (3) have Mira, Fiverr's headhunter, scope the project and find the best talent for it. Then ask which they would like. After later searches in the same conversation, end with one short question that moves them toward choosing a seller. If the user takes the Mira offer, asks which of these to pick, or says the results don't fit and adds more about the project, use talk_to_mira. Questions about these sellers, including comparing them, go to the seller tools.

A freelancer's bio, notable clients, services, review summary and latest reviews, for the freelancer details view.

Use this tool to check a specific freelancer's background, location, and languages once you already have their username, typically returned by find_freelancers. This is for background and credibility checks on a named seller, not for discovering new freelancers — for that, use find_freelancers.

Use this tool to check a named seller's aggregate rating score and review count, to quickly answer whether a specific freelancer is worth hiring. For the actual text of what clients wrote, use list_seller_reviews instead.

Use this tool to see the gigs and prices a named seller currently has published, once you already have their username. Only published gigs are included, so a page may return fewer than `limit` items — keep requesting pages until `has_next_page` is `false`.

Use this tool to read the actual text of reviews left for a named seller, paginated. Use it when the user wants to know what past clients actually said about a specific freelancer, not just their rating score — for the rating and count alone, use get_seller_reviews_summary.

A user's rating and optional comment about the Fiverr connector, from a widget's feedback form.

Sign in or sign up on Fiverr once the brief is ready, and the brief goes with them. WHEN TO CALL IT: as soon as a talk_to_mira result carries ``briefReady``, and whenever the user wants to move on from the brief: see who could do the work, get quotes, approve the brief, hire. Finding and hiring the people happens in Mira on Fiverr, not in this chat, and this is the way there. Offer it once when the brief becomes ready; never push the user to sign in before they want to move on. IF THE USER DECLINES TO SIGN IN but still wants to see freelancers now, call find_freelancers with the ``summary`` this tool returned as ``brief``, its budget fact as the budget filter and its timing fact as the delivery time (skip any with a null value). Do this only when they ask; never offer search in place of signing in. What it returns, by ``state``: - "ready": ``signInUrl``, a link that signs the user in to Fiverr (a new user signs up on the same page) and moves this conversation's brief into their account, where Mira opens it ready to go. It works for one day; call this again for a fresh one. - "brief_not_ready": Mira still needs a few details. Keep the conversation going with talk_to_mira and call this again once a result carries ``briefReady``. - "moved": the user already signed in and the brief is in their account. ``openUrl`` opens it in Mira. - "no_conversation": Mira has nothing from this user yet. Send their request to talk_to_mira first. Before the move it also carries the brief: ``title``, ``summary``, ``facts`` (talent, timing and budget; a null ``value`` is one the user has not settled) and every section in ``brief``. WHAT THE USER SEES: on a card host the card shows the brief (its title, summary, talent, timing and budget), a "Sign up to continue" button that opens the link and a "View brief" button that opens the whole brief inside the card (once moved, an "Open in Mira" button instead). So do not paste the link or the brief again; one short line pointing at the button is enough. Before the brief is ready the card shows the brief so far with NO sign-up button, so do not mention one. With no card, give the user the link yourself as a clickable link, with one line on what it does: they sign up or sign in with Fiverr and their brief comes with them. WORKSPACE KEY: this connector has no sign-in, so every reply carries workspaceKey and every call passes it back as workspace_key. Leave it empty only on the first talk_to_mira of a conversation, which starts the workspace. Every other Mira tool refuses a call without it, and a later talk_to_mira without it starts another, empty workspace. Never invent a key.

Talk to Mira, Fiverr's headhunter, and return her reply. USE THIS when the user asks for help with the hiring itself, not just to see people: writing or scoping a brief for a project, getting quotes, what the work would cost, choosing between options (agencies, freelancers, approaches), working out what kind of talent a project needs ("no idea what kind of developer I need"), or whether to outsource at all. It covers any kind of work, from a designer, developer, video editor or translator through an accountant, a marketer, a lawyer to review a contract, a bookkeeper, a voice actor: what makes it Mira's is that the user wants help with the hiring itself. Also use it after find_freelancers results when the user takes the Mira offer, or says the results don't fit and adds more about the project. Once a hiring conversation is underway, the user's further messages about it go here too, their answers to Mira's questions included. USE find_freelancers INSTEAD when the user wants to find, browse or compare freelancers, or describes a need or a problem without asking for help with the hiring itself ("find me a python developer", "my site looks dated", "I need a logo for my coffee shop"). A budget or deadline alone does not make it a Mira conversation. Also when the user, during a Mira conversation, asks to see freelancers right now: search with what they told Mira, and tell them in one line that Mira's brief stays open. SEND ONLY WHAT MIRA NEEDS: the user's own words about the work they want done. Never the rest of the conversation, never what they said about other topics, and no personal details they have not chosen to tell Mira (contact details, account numbers, passwords or anything else sensitive). If a message mixes the hiring need with other things, send only the part about the need. When the user moves to Mira from search results, send their own description of the project, from earlier in the chat too, plus what they just added. Mira runs the real conversation server-side, with the live Fiverr market behind her, so anything you improvise both contradicts her and never reaches her. Pass those words VERBATIM as ``message``. A ``status`` of "working" with a non-empty reply is NORMAL: Mira answered and her team is still updating the brief in the background; do not wait or mention it. Only when ``reply`` says she is still working: on a card host the card picks her reply up itself, so add nothing; with no card, call this again after a moment with an EMPTY ``message`` and the returned ``turnId`` as ``turn_id``, which picks up her reply and sends nothing. When the result carries ``briefReady``, the brief is ready: call take_brief_to_mira to give the user the way on to Fiverr. If Mira talks about approving the brief or starting her search, that is the same step: it happens in Mira on Fiverr, through take_brief_to_mira. A ``state`` of "moved" means the user already took this conversation to Fiverr: nothing was sent, so relay the reply and its link. One conversation is one hiring need: never mention projects, and if the user wants to hire for a second, unrelated role, suggest they start a new conversation for it. WHAT THE USER SEES: on a host that renders the Mira card (Claude.ai, Claude Desktop, ChatGPT) the card shows ``reply`` as Mira's own message and any ``widget`` (her question) with its answer options as buttons, and the user answers in the card itself. So do NOT repeat the reply, the question or its options: one short line pointing at the card is the most to add, and usually nothing is right. The result's ``assistantNote`` says the same. Only on a host with no card (a terminal, the API) relay ``reply`` VERBATIM as Mira's words, and list a widget's ``options`` after it as plain text (one short line each, by their labels). If the user answers one of her questions in chat instead, send that answer here as the next ``message``. ``widget_id`` and ``option_id`` are filled by the Mira card itself when the user taps an answer in it. Leave both empty. WORKSPACE KEY: this connector has no sign-in, so every reply carries workspaceKey and every call passes it back as workspace_key. Leave it empty only on the first talk_to_mira of a conversation, which starts the workspace. Every other Mira tool refuses a call without it, and a later talk_to_mira without it starts another, empty workspace. Never invent a key.