listbee-mcp
OfficialProvides Stripe Connect integration for accepting payments, including onboarding, disconnection, and readiness checks.
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., "@listbee-mcpCreate a listing for a PDF guide at $10"
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.
listbee-mcp
MCP server for ListBee — commerce API for AI agents. 20 tools.
Connect
Remote (zero install): https://mcp.listbee.so — for ChatGPT Apps, Claude API Connector, remote agents. Each request needs Authorization: Bearer lb_... header.
Local (stdio): npx -y listbee-mcp — for Claude Desktop, Cursor, VS Code, Cline.
Related MCP server: ebay-mcp
Golden Path
Three calls to go from zero to a live, selling product page:
create_listing → get_listing → publish_listing
name, price check status go live1. Create — set deliverable for managed auto-delivery, or agent_callback_url for async agent fulfillment
{
"name": "50 Cold Outreach Templates",
"price": 1900,
"deliverable": { "type": "url", "value": "https://cdn.example.com/templates.zip" }
}2. Inspect readiness — get_listing tells you what's missing and how to fix it
3. Publish — publish_listing makes the product page live
Bootstrap (no API key)
Don't have a ListBee account yet? Start the MCP server without a key — it exposes bootstrap tools for account creation:
bootstrap_start → bootstrap_verify
send OTP email verify 6-digit → get API key + Stripe onboarding URLnpx -y listbee-mcp # no --api-key neededbootstrap_verify returns { account_id, api_key, stripe_onboarding_url }. Store the key immediately, then restart the MCP session with --api-key lb_... to unlock all tools.
After restarting with the key, call bootstrap_poll to check whether Stripe Connect onboarding is complete before creating listings.
For the HTTP transport, sessions initialized without a Bearer header are automatically bootstrap-only. After bootstrap, open a new session with the key to access the full tool set.
Install
Requires Node.js 20+.
Claude Desktop
~/.claude/claude_desktop_config.json
{
"mcpServers": {
"listbee": {
"command": "npx",
"args": ["-y", "listbee-mcp", "--api-key", "lb_..."]
}
}
}Or with an env var:
{
"mcpServers": {
"listbee": {
"command": "npx",
"args": ["-y", "listbee-mcp"],
"env": {
"LISTBEE_API_KEY": "lb_..."
}
}
}
}Cursor
.cursor/mcp.json
{
"mcpServers": {
"listbee": {
"command": "npx",
"args": ["-y", "listbee-mcp", "--api-key", "lb_..."]
}
}
}Claude Code
claude mcp add listbee -- npx -y listbee-mcp --api-key lb_...CLI
npx -y listbee-mcp --api-key lb_...Remote / HTTP Transport
For hosted deployments (ChatGPT Apps, Claude API Connector, remote agents):
npx -y listbee-mcp --transport http --port 3000Each connecting agent provides their API key via Authorization: Bearer header.
Docker
docker build -t listbee-mcp .
docker run -p 8080:8080 listbee-mcpHealth Checks
GET /health— basic livenessGET /ready— confirms tools are loaded
Options
Flag | Env var | Default | Description |
|
| — | ListBee API key. Optional — omit to start in bootstrap-only mode. |
|
|
| API base URL |
| — |
| Transport mode |
|
|
| HTTP port (http mode only) |
| — | all tools | Comma-separated list of tools to load |
| — | — | Show help |
Selective tool loading — load only what you need:
npx -y listbee-mcp --api-key lb_... --tools create_listing,get_listing,publish_listingTools
Bootstrap (no API key required for start + verify)
Tool | Description |
| Send a one-time passcode to an email address. Step 1 of 2 for account creation. |
| Verify the OTP from email. Issues the API key and Stripe onboarding URL. Step 2 of 2. Store the key immediately. |
| Poll Stripe Connect onboarding readiness. Returns |
Account
Tool | Description |
| Get the account's full state including readiness and billing status. |
| Update account-level settings (display name, bio, avatar, GA tracking, events callback URL). |
| Permanently delete the account and all data. Irreversible. |
Listings
Tool | Description |
| Create a new listing for sale. Set |
| Get full listing state including readiness. Call after every change. |
| Update title, price, deliverable, or other listing details. |
| List all listings for the current account. |
| Publish a listing so buyers can access the product page. |
| Permanently delete a listing. |
Orders
Tool | Description |
| See all sales and order status. |
| Get full order details including buyer info, payment, and unlock URL. |
| Push a deliverable to a buyer or mark as fulfilled (external fulfillment). Accepts optional |
| Issue a full refund for an order through Stripe. |
| Re-queue |
Stripe
Tool | Description |
| Start Stripe Connect onboarding. Returns a URL — the human must open it in a browser. |
| Disconnect the Stripe account from ListBee. |
API Keys
Tool | Description |
| Self-revoke the API key used to authenticate this call. Idempotent. Use when credential is compromised. |
Readiness
Every listing response includes a readiness object that tells you exactly what's needed before the listing can go live — and how to fix it.
{
"readiness": {
"sellable": false,
"publishable": false,
"actions": [
{
"code": "connect_stripe",
"kind": "human",
"message": "Connect a Stripe account to accept payments.",
"resolve": {
"method": "POST",
"endpoint": "/v1/account/stripe/connect"
}
}
],
"next": "connect_stripe"
}
}What to do with it:
readiness.sellable—truemeans buyers can purchase right nowreadiness.publishable—truemeans you can callpublish_listingreadiness.actions— list of what's blocking, each withkind: "api"orkind: "human"apiactions: the agent handles them (call the endpoint inresolve)humanactions: requires human input (show themessageandurl)
readiness.next— the highest-priority action code to resolve first
The pattern: create_listing → get_listing → resolve each api action → surface human actions to the user → publish_listing when publishable is true.
Fulfillment Modes
ListBee supports two fulfillment modes, set at listing creation:
Managed (
STATIC) — setdeliverableon the listing. ListBee auto-delivers the content to buyers on payment via an unlock page and email.Async agent (
ASYNC) — setagent_callback_urlon the listing. ListBee fires a webhook to your agent on payment; your agent callsfulfill_orderwith the generated content.
For ASYNC mode, use order_redeliver if your callback handler missed an event.
Debugging
Use MCP Inspector for interactive testing:
npx @modelcontextprotocol/inspector npx -y listbee-mcpGet an API Key
console.listbee.so — sign in, go to API Keys.
Links
API Reference — full endpoint docs
OpenAPI Spec — machine-readable spec
Docs — guides and integration examples
CHANGELOG — version history
npm — npm package
GitHub — source
License
Apache-2.0
Available Tools
2 toolsbootstrap_startA
Step 1 of 2. Emails an OTP and returns a single-use bootstrap_token plus the account_id. Token TTL 10 min. Flow: bootstrap_start → bootstrap_verify. No API key required.
When to use: Kicking off a new seller account. The human will receive a 6-digit OTP by email; bring the code back and call bootstrap_verify.
Tips:
Human interaction required: ask for their email, then tell them to check inbox
bootstrap_token expires in 10 minutes — call bootstrap_verify promptly
Disposable email domains are blocked
Note: This action requires human intervention. You cannot complete it yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Seller email. OTP is sent to this address. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it sends an OTP email, the token TTL (10 min), and that human interaction is required. Annotations indicate non-readonly, non-destructive, non-idempotent, which aligns with the description. No contradictions.
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?
Well-structured with clear sections: core action, when to use, tips, note. Front-loaded with the most critical information. Every sentence adds value without redundancy.
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?
Despite no output schema, the description explains the return values (bootstrap_token, account_id). Covers all important behavioral aspects: OTP email, time limit, human intervention, blocked domains. Complete for a single-parameter 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 already covers the email parameter with format and pattern. Description adds that OTP is sent to this address, which is implicit. With 100% schema coverage, 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?
Clearly states it is step 1 of a 2-step flow, emails an OTP, and returns bootstrap_token plus account_id. The sibling bootstrap_verify is explicitly mentioned, distinguishing their roles.
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?
Explicitly says when to use: 'Kicking off a new seller account.' Provides actionable tips: ask for email, tell human to check inbox, call bootstrap_verify promptly, and disposable domains blocked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bootstrap_verifyA
Step 2 of 2. Verifies the OTP, issues the first API key (shown once — store immediately), and returns Stripe onboarding URL. Hand the Stripe URL to the human; poll bootstrap_poll until ready.
When to use: The human pasted the OTP. Call this once with bootstrap_token + otp_code to mint the API key.
Tips:
Store the api_key IMMEDIATELY — it is shown once and cannot be recovered
After receiving the key, restart this MCP session with the key to unlock all tools
After 5 failed OTP attempts the bootstrap_token is invalidated — call bootstrap_start again
Hand the stripe_onboarding_url to the human; poll bootstrap_poll every 30s until ready=true
Note: This action requires human intervention. You cannot complete it yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| bootstrap_token | Yes | Token from /start. | |
| otp_code | Yes | 6-digit OTP pasted from email. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: API key shown once, session must be restarted, token invalidated after 5 failures, requires human intervention. No contradiction with annotations.
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?
Well-structured with headings; every sentence adds value; no redundancy.
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?
Covers all aspects: what tool does, inputs, outputs, post-actions (store key, hand URL, poll), error handling, and references sibling tools.
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 has 100% description coverage, but description adds context (token from /start, OTP from email) that aids correct usage.
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 it verifies OTP, issues API key, and returns Stripe URL. Distinguishes from bootstrap_start as step 2.
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?
Explicitly says 'When to use: the human pasted the OTP' and describes failure handling (call bootstrap_start again after 5 failures).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
bootstrap_start and bootstrap_verify have clearly distinct roles: one initiates the flow by sending an OTP, the other completes it by verifying the OTP and issuing credentials. No overlap.
Both tools follow the bootstrap_verb pattern consistently, making the flow's stages immediately recognizable.
Only 2 tools are provided, which is thin even if the server is scoped solely to account bootstrapping. The description hints at additional tools unlocked after bootstrap, suggesting the set here is intentionally minimal but still feels incomplete.
The bootstrap flow itself is fully covered (start → verify), but for a server named listbee-mcp, one would expect tools for managing listings, orders, payments, etc. The surface is severely incomplete for the implied domain.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Run an eBay seller account from your AI assistant: orders, listings, stock, fees and payouts.
Stripe payments for AI agents. Create links, verify, manage customers.
Directory of APIs, merchants, and tools AI agents can actually use.
Stripe-native marketplace where AI agents discover and pay per call for API services.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI assistants to manage consignment and retail business operations through the ConsignCloud API, including inventory management, sales tracking, vendor accounts, and analytics.261GPL 3.0
- AlicenseCqualityAmaintenanceProvides AI assistants with comprehensive access to eBay's Sell APIs, including 325 tools for inventory management, order fulfillment, marketing campaigns, analytics, and more.100294141MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to manage WooCommerce stores, including products, orders, customers, categories, coupons, attributes, variations, order notes, refunds, reports, payment gateways, meta data, reviews, settings, data, posts, and system status through natural language.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to interact with WooCommerce stores via the WooCommerce REST API, supporting operations like listing products, orders, and customers.18MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/listbee-dev/listbee-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server