Provides tools to manage Fiverr seller account: list, create, update, pause, activate, and delete gigs; manage orders and messages; view analytics; update profile.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fiverr-mcp Show me my recent orders and their statuses."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give Claude Code live access to your Fiverr seller account. Manage gigs, orders, messages, analytics, and your profile directly from your AI assistant — no API key required.
How it works: A Chrome/Edge extension runs inside your already-logged-in Fiverr tab and acts as a bridge. Claude talks to the extension over a local native messaging channel. Your credentials never leave your browser.
Claude Code ──stdio──▶ MCP server (Node.js)
│
native messaging (stdin/stdout)
│
Chrome / Edge extension
│
fiverr.com (your logged-in tab)No credentials are stored anywhere. The extension uses your existing browser session.
Related MCP server: byob
Node.js 18+
Chrome or Microsoft Edge (desktop)
Claude Code CLI — install guide
A Fiverr seller account, logged in in your browser
Windows is fully supported. macOS/Linux support for the native messaging setup is a work in progress (PRs welcome).
git clone https://github.com/marwankous/fiverr-mcp.git
cd fiverr-mcp
npm install
npm run buildThe extension lives in the extension/ folder. You load it as an unpacked extension — no Chrome Web Store required.
Chrome:
Open chrome://extensions in your browser
Toggle Developer mode on (top-right corner)
Click Load unpacked
Select the extension/ folder inside this repo
Edge:
Open edge://extensions
Toggle Developer mode on (left sidebar)
Click Load unpacked
Select the extension/ folder inside this repo
You should see "Fiverr MCP Bridge" appear in your extensions list.
Every unpacked extension gets a unique ID. You need it for the next step.
On the extensions page (chrome://extensions or edge://extensions), find Fiverr MCP Bridge
Make sure Developer mode is on — the ID is only visible when it is
The ID appears directly below the extension name as a 32-character string of lowercase letters:
Fiverr MCP Bridge
ID: abcdefghijklmnopabcdefghijklmnopCopy that string
Copy it — you'll paste it in the next step
This step links your browser to the bridge process so the extension can launch it automatically.
npm run setupThe script will ask you to paste your extension ID, then writes the required manifest files and registry keys for Chrome and Edge.
What it does:
Writes com.fiverr_mcp.bridge.json to AppData\Roaming\Google\Chrome\NativeMessagingHosts\
Writes the same to AppData\Roaming\Microsoft\Edge\NativeMessagingHosts\
Adds the registry keys HKCU\Software\Google\Chrome\NativeMessagingHosts\com.fiverr_mcp.bridge and the Edge equivalent
claude mcp add fiverr-mcp -- node "/absolute/path/to/fiverr-mcp/dist/index.js"Replace /absolute/path/to/fiverr-mcp with the actual path where you cloned the repo.
Verify it's registered:
claude mcp listAfter running setup, go back to chrome://extensions (or edge://extensions) and click the reload icon on the Fiverr MCP Bridge extension. This picks up the newly registered native host.
Make sure you are logged into Fiverr in Chrome or Edge. The extension operates on your active session — it needs a Fiverr tab open to execute commands.
claudeAll tools are now available. Try:
list my fiverr gigsTool | What it does |
| List all your gigs with status, impressions, clicks, and orders |
| Full details of a specific gig |
| Create and publish a new gig (title, description, packages, FAQ, requirements) |
| Edit any field on an existing gig |
| Pause (deactivate) a gig |
| Re-activate a paused gig |
| Permanently delete a gig |
| Update your bio, professional title, display name, skills, or languages |
| List orders, optionally filtered by status |
| Full details of a specific order |
| List your inbox conversations |
| Full message thread for a conversation |
| Impressions, clicks, and orders over a date range |
| Run arbitrary JavaScript in your Fiverr tab (power users / automation) |
Show me all my active gigs and their click-through rates this month.Create a new gig titled "I will build a local AI assistant for your business"
with a basic package at $50, standard at $100, and premium at $200.Update the description on gig 123456789 to focus more on small businesses.What orders do I have active right now? Summarize what each buyer needs.Show me my last 30 days of analytics. Which gig is performing best?Update my profile bio to highlight RAG systems and local AI deployment.list_gigsNo input required.
// Returns:
{ id: string; title: string; status: "active" | "paused" | "denied"; impressions: number; clicks: number; orders: number }[]get_gig · pause_gig · activate_gig · delete_gig{ gigId: string }create_gig{
title: string
category?: string
subcategory?: string
description?: string
tags?: string[] // max 5
packages?: {
name: "basic" | "standard" | "premium"
price: number
deliveryDays: number
revisions: number
description: string
}[]
faq?: { question: string; answer: string }[]
requirements?: string[]
}update_gigSame as create_gig, all fields optional, plus gigId: string (required).
update_profile{
displayName?: string
professionalTitle?: string
bio?: string
skills?: string[]
languages?: { lang: string; level: "basic" | "conversational" | "fluent" | "native" }[]
}list_orders{ status?: "active" | "completed" | "cancelled" }list_messages{ unreadOnly?: boolean }get_conversation{ conversationId: string }get_order{ orderId: string }get_analytics{ gigId?: string; from?: string; to?: string } // dates: YYYY-MM-DDexecute_js{
code: string // body of an async function — use return to send data back
url?: string // navigate to this Fiverr URL first
reload?: boolean // force-reload the tab before executing
}"Fiverr MCP bridge not reachable"
Chrome or Edge must be open with a Fiverr tab
Make sure you are logged into Fiverr
Confirm the extension is enabled on chrome://extensions
Re-run npm run setup and reload the extension if you moved the repo folder
"Fiverr MCP command timed out"
The Fiverr page took too long to respond — just retry
Check if Fiverr is showing a CAPTCHA or session-expired prompt in your browser
Tools not appearing in Claude Code
Run claude mcp list and confirm fiverr-mcp is listed
Start a new Claude Code session after registering the MCP server
Extension ID changed after browser restart
Unpacked extension IDs are stable as long as you don't remove and re-add the extension
If you reload it from a different path, the ID changes — re-run npm run setup with the new ID
On macOS or Linux
The npm run setup script currently targets Windows (AppData paths + registry)
You can manually write the native messaging manifest to:
macOS Chrome: ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/
Linux Chrome: ~/.config/google-chrome/NativeMessagingHosts/
PRs to automate this are welcome
npm run dev # run MCP server with tsx (no build needed)
npm test # run vitest test suite
npm run build # compile src/ → dist/ and bridge/ → bridge/dist/Project structure:
extension/ Chrome/Edge extension (content scripts + background)
background.js Routes MCP commands to the correct Fiverr tab
content/
interceptor.js Intercepts Fiverr's internal API responses
router.js Dispatches commands to action handlers
actions/ Per-feature action handlers (gigs, orders, profile…)
src/ MCP server (TypeScript)
index.ts Tool definitions and server entry point
bridge-client.ts Native messaging client
schemas.ts Shared zod schemas
tools/ One file per tool group
bridge/ Native messaging host (Node.js)
index.ts Bridges Chrome native messaging ↔ TCP socket
scripts/
setup-native-host.ts Registers the native host for Chrome and EdgePull requests are welcome. A few areas where help is appreciated:
macOS / Linux setup script — the current npm run setup only handles Windows
Additional tools — buyer requests, custom offers, gig packages editor
Firefox support — native messaging works in Firefox with a slightly different manifest format
Please open an issue before starting a large change so we can coordinate.
MIT — see LICENSE
Re-activate a paused Fiverr gig
| Name | Required | Description | Default |
|---|---|---|---|
| gigId | Yes | The gig ID (from list_gigs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the effect (activates) but omits details like side effects, reversibility, or what the tool returns, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with no extraneous words; front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description is adequate but lacks information about return values or success indicators, especially given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add extra meaning beyond the schema's description of gigId; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (re-activate), the resource (paused Fiverr gig), and the condition (paused), making it distinguishable from siblings like pause_gig or delete_gig.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for paused gigs but does not provide explicit guidance on when to use versus alternatives or any prerequisites beyond the implied paused state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and publish a new Fiverr gig
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Gig title | |
| category | No | ||
| subcategory | No | ||
| description | No | ||
| tags | No | ||
| packages | No | ||
| faq | No | ||
| requirements | No | ||
| gallery | No | Local file paths to images/videos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'create and publish' without detailing potential side effects (e.g., immediate visibility, billing implications), authentication requirements, rate limits, or error handling. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the single sentence is brief, it is under-specified for a tool with 9 parameters. Conciseness should not come at the expense of completeness. A well-structured description would front-load key details; here, critical information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain return values, validation rules, failure behavior, or any lifecycle considerations. A minimal viable description would need to cover these aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 22% description coverage (only title and gallery have descriptions). The description adds no parameter-level information. Many important parameters (category, subcategory, tags, packages, etc.) remain unexplained, leaving the agent to infer their meaning without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create and publish a new Fiverr gig' clearly identifies the verb (create and publish) and resource (Fiverr gig). It effectively distinguishes this tool from siblings like update_gig, delete_gig, or pause_gig, which handle different operations on existing gigs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., authentication, account setup) or when not to use it (e.g., if editing an existing gig, use update_gig). The absence of any contextual usage advice reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a Fiverr gig
| Name | Required | Description | Default |
|---|---|---|---|
| gigId | Yes | The gig ID (from list_gigs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'permanently delete' implying irreversibility and destructiveness, but lacks details on side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence efficiently communicates the tool's purpose without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool, the description covers the core action. However, given no output schema and no usage context, it's minimal but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains 'gigId' well. Description adds no extra meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Permanently delete a Fiverr gig' with specific verb 'delete' and resource 'Fiverr gig'. Clearly distinguishes from siblings like 'pause_gig' and 'update_gig'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives (e.g., pausing). Does not specify prerequisites or when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run arbitrary JavaScript in the MAIN world of a Fiverr browser tab and return the result. Use this to inspect the DOM, intercept data, or perform any action on the page. The code runs as the body of an async function so you can use await and return values.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript source to execute (body of an async function — use return to send data back) | |
| url | No | Fiverr page URL to navigate to first (default: current Fiverr tab) | |
| reload | No | Force-reload the tab before executing (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the code runs in the MAIN world, as an async function, and returns results. It implies mutability ('perform any action'), but does not disclose potential side effects like triggering events, CSP restrictions, or error handling behavior. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with action and purpose. Every sentence adds value: first states what it does, second lists use cases, third explains execution context. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description covers purpose, usage, and execution context. It is missing details about the format of returned data when errors occur, and lacks mention of page mutation warnings. Still, it feels mostly complete for a scripting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds minor context for the 'code' parameter (async function body, use return) but does not add significant meaning beyond the schema for 'url' or 'reload'. Baseline 3 is appropriate as the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs arbitrary JavaScript in the MAIN world of a Fiverr browser tab and returns the result. It lists use cases (inspect DOM, intercept data, perform any action) and provides technical context (async function body). This strongly distinguishes it from sibling tools which are focused on gig/order management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this for inspecting the DOM, intercepting data, or performing any action on the page, giving clear when-to-use guidance. It does not explicitly mention when not to use or alternative tools, but the context of sibling tools makes alternatives obvious. The gap is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get gig analytics (impressions, clicks, orders) for your gigs
| Name | Required | Description | Default |
|---|---|---|---|
| gigId | No | Filter to a specific gig ID | |
| from | No | Start date (YYYY-MM-DD) | |
| to | No | End date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Only states it retrieves analytics data, but does not disclose limitations, prerequisites, data freshness, or side effects. Lacks behavioral details beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no wasted words. Effectively front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
List of metrics is helpful, but no output schema provided. Could specify whether returns per-gig or aggregated, and date range behavior. Adequate but not comprehensive for a tool with optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for gigId, from, and to. Description adds context ('for your gigs') but does not enhance parameter meaning beyond schema. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Get' and resource 'gig analytics' with specific metrics (impressions, clicks, orders). Differentiates from siblings like get_gig or list_gigs by explicitly targeting analytics data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No exclusion criteria or context for when other tools might be more appropriate. Implicitly used for analytics, but no explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full message thread for a conversation
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | The conversation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states 'get full message thread' implying a read operation, but does not mention pagination, limits, authentication, or what 'full' means (e.g., includes attachments). Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with key information. It is appropriately brief but could benefit from a little more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description is incomplete. It does not explain return format, potential errors, or how to interpret results. Sibling tools suggest a platform context, but more context is needed for the agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the schema already documents it. The description adds no additional context beyond the parameter name. Baseline of 3 is appropriate; no extra value provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a full message thread for a conversation, with a specific verb ('get') and resource. It distinguishes from siblings like 'list_messages' by implying a single conversation focus, though it could be more explicit about what 'full' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_messages. There are no use-case examples, prerequisites, or conditions that would make this tool inappropriate. The agent must infer entirely from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific gig
| Name | Required | Description | Default |
|---|---|---|---|
| gigId | Yes | The gig ID (from list_gigs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior, but it only says 'Get full details' without specifying what that entails (e.g., read-only nature, side effects, or performance). The agent is left guessing about the tool's implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It could be slightly more informative, but it is effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The absence of an output schema and the minimal description leave the agent uncertain about the response format and content. Given the tool's simplicity, more context (e.g., typical fields returned) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter's description in the schema already explains it as 'The gig ID (from list_gigs)'. The tool description adds no additional meaning, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get full details') and the target resource ('a specific gig'). It effectively distinguishes from sibling tools like list_gigs (which lists multiple) and create_gig (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool. While the parameter 'gigId' implies use after list_gigs, the description does not mention prerequisites or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific Fiverr order
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only states 'get full details' but does not disclose what details are included, authorization needs, or that it is a read-only operation without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. However, it could be slightly longer to include essential guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally adequate but lacks usage guidance and behavioral detail that would help an agent differentiate from list_orders.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description of orderId ('The order ID') adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (Get) and resource (full details of a specific Fiverr order). Differentiates well from sibling list_orders which retrieves multiple orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_orders or when not to use it. Does not mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your Fiverr gigs with status and metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only states 'list all your gigs' without disclosing read-only nature, authentication needs, rate limits, or response format. Lacks significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 8 words, front-loaded with verb and resource. No wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions 'status and metrics' as return fields. However, does not elaborate on structure or other potential fields. For a simple list tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema description coverage is 100%. No parameter details needed; baseline score is 4 as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (list), resource (your Fiverr gigs), and scope (all), plus additional info (status and metrics). Distinguishes from sibling tools like get_gig.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implicitly suggests listing all gigs, but does not compare with alternatives like get_gig. Minimum viable for a simple list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your Fiverr inbox conversations
| Name | Required | Description | Default |
|---|---|---|---|
| unreadOnly | No | Return only unread conversations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose whether results are paginated, ordered, or if there are any side effects. For a list operation, basic behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 5 words with no redundancy. It is efficient, though slightly too minimal for full clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, no output schema, no annotations), the description is adequate but lacks usage guidance and behavioral details. It meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the single parameter 'unreadOnly'. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and clearly identifies the resource as 'Fiverr inbox conversations'. It distinguishes from siblings like get_conversation (which likely targets a specific conversation) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as get_conversation. Lacks context about appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your Fiverr orders (active, completed, or cancelled)
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only indicates a read operation ('List') and shows possible status filters. Missing details on pagination, rate limits, or whether results are ordered. Fails to fully disclose behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, succinct sentence with no extraneous content. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description covers essential purpose and filter options. However, lacks output schema and does not mention sorting, pagination, or typical limits, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description adds meaning by listing status enum values, but does not clarify that the parameter is optional, default behavior when omitted, or semantics of each status value. Incomplete compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List your Fiverr orders' with specific verb and resource, and enumerates status options, differentiating from get_order (single order) and list_gigs (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_order or list_gigs. Implicitly suggests filtering by status, but lacks context on default behavior or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause (deactivate) a Fiverr gig
| Name | Required | Description | Default |
|---|---|---|---|
| gigId | Yes | The gig ID (from list_gigs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing side effects, state changes, or reversibility. It fails to inform the agent about the implications of pausing a gig.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of four words, efficiently conveying the core function. However, it is slightly too terse, missing useful context that could be added without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description should provide more behavioral context (e.g., effect on gig, if reversible). It lacks information about return values or side effects, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the sole parameter 'gigId' as 'The gig ID (from list_gigs),' achieving 100% coverage. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Pause (deactivate)' and resource 'Fiverr gig', clearly distinguishing it from siblings like activate_gig and delete_gig. It conveys the exact action performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as activate_gig or delete_gig. The description does not mention context or preconditions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update title, description, or tags on an existing Fiverr gig
| Name | Required | Description | Default |
|---|---|---|---|
| gigId | Yes | The gig ID (from list_gigs) | |
| title | No | ||
| category | No | ||
| subcategory | No | ||
| description | No | ||
| tags | No | ||
| packages | No | ||
| faq | No | ||
| requirements | No | ||
| gallery | No | Local file paths to images/videos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'update' (a write operation) but fails to disclose behavioral traits such as idempotency, authorization requirements, rate limits, or what happens to unspecified fields. The description also misleads by mentioning only three fields whereas the schema includes many more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, but it is too brief and omits important details. It sacrifices completeness for brevity, missing opportunities to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 10 parameters and no output schema, the description is inadequate. It fails to explain return values, error conditions, or the full set of updatable fields, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 20% of schema parameters have descriptions, and the tool description only adds meaning for title, description, and tags, ignoring other parameters like category, subcategory, packages, etc. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Update' and the resource 'existing Fiverr gig', listing specific fields (title, description, tags). This effectively distinguishes it from sibling tools like create_gig or delete_gig.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for updating a gig but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like needing the gig ID from list_gigs. The schema does reference list_gigs in gigId description, but the description itself lacks such context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update your Fiverr seller profile (bio, title, name, picture, skills, languages)
| Name | Required | Description | Default |
|---|---|---|---|
| displayName | No | Your public display name | |
| professionalTitle | No | Your seller tagline | |
| bio | No | Your seller description | |
| profilePicture | No | Local file path to profile image | |
| skills | No | List of skills | |
| languages | No | Spoken languages with proficiency level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'update' which implies mutation, but does not specify side effects, required permissions, rate limits, or whether partial updates are supported. This incomplete disclosure hinders safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the tool's action and scope. It is front-loaded and contains no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with a fully described input schema and no output schema, the description is adequate but minimal. It does not cover concepts like optionality, clearing fields, or expected behavior when certain fields are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all 6 parameters. The description merely lists the fields without adding new semantic meaning, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates a Fiverr seller profile and enumerates the specific fields that can be updated (bio, title, name, picture, skills, languages). This distinguishes it from sibling tools that deal with gigs and orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for updating the seller profile, but it lacks explicit guidance on when to use it versus alternatives. However, the sibling tools are distinctly different in purpose, so confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action or resource. Tools like list_gigs, get_gig, create_gig, etc. are clearly separated; list_messages and get_conversation serve different granularities. No overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., activate_gig, list_orders, get_analytics). No deviation or mixing of conventions.
14 tools cover the core domains of gig, order, message, analytics, and profile management without bloat or excessive minimalism. Well-scoped for a Fiverr seller assistant.
The tool surface covers essential CRUD for gigs, listing orders/messages, analytics, and profile updates. Missing send message or cancel order, but execute_js can fill gaps. Minor gaps overall.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run an eBay seller account from your AI assistant: orders, listings, stock, fees and payouts.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Give AI agents the LinkedIn tools to find, qualify, engage, and follow up with prospects.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/marwankous/fiverr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
