This server provides a full eBay buyer-side workflow integration, enabling search, watchlist management, bidding, and purchasing through a safety-gated MCP interface.
Search & Item Discovery
search — Search eBay listings by keyword with filters for category, condition, price range, currency, sort order, and marketplace
get_item — Fetch full details for a specific item by ID, including description, shipping, seller info, and return terms
MyeBay Reading
get_watchlist — View your currently watched items
get_active_bids — See auctions where you have active bids
get_won_items / get_purchase_history — List items won or purchased
get_lost_items — View auctions you bid on but didn't win
Watchlist Management
add_to_watchlist / remove_from_watchlist — Manage your eBay watchlist (reversible, no money committed)
Money-Committing Actions (safety-gated: confirm-amount match, $500 cap, human-in-the-loop OS dialog)
place_bid — Place a proxy bid on an auction
buy_now — Instantly purchase a Buy It Now listing
make_best_offer — Submit a Best Offer on eligible listings
Authentication
start_user_auth / complete_user_auth — OAuth2 flow to obtain and manage user tokens
Server Management
server_info — Get server version, active host (sandbox/production), and config locations
list_hosts — List all configured hosts with their status and credential availability
Allows interacting with eBay's APIs to search items, manage watchlist, place bids, buy items, and retrieve purchase history.
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., "@ebay-mcp search for vintage leather jacket"
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.
MCP server for eBay buyer-side workflows: search, watch, bid, buy, manage MyeBay. Hybrid stack — modern Buy/Browse REST API for search and item lookup, legacy Trading API (still functional in 2026) for everything stateful.
⚠️ Beta (v0.5.0). Browse + Trading APIs wired, sandbox + production both supported. All 15 tools are production live-verified — including the three money-commit tools which have been used to close real eBay transactions through the safety stack (confirm-amount gate + $500 cap + OS-modal Yes/No dialog). Read the money commits section before enabling production.
search, get_item (Browse API)
get_watchlist, get_active_bids, get_won_items, get_lost_items, get_purchase_history (Trading API)
add_to_watchlist, remove_from_watchlist
place_bid(item_id, max_bid_amount, confirm_amount, ...) — Trading PlaceOffer with Action=Bid. Proxy bid on an auction.
buy_now(item_id, confirm_amount, ...) — Trading PlaceOffer with Action=Purchase. Commits to a Buy-It-Now sale.
make_best_offer(item_id, offer_amount, confirm_amount, ...) — Trading PlaceOffer with Action=BestOffer. Submits an offer the seller can accept/counter/decline.
Safety stack (every money tool):
Confirm-amount gate. Every call requires confirm_amount exactly equal to the bid/buy/offer amount. The LLM has to repeat the dollar figure; mismatches return a structured refusal payload (not an exception) so the LLM can read it and retry with corrected params.
$500 per-call cap. Amounts above $500 refuse with reason: "cap_exceeded". Two ways to authorize a higher spend:
Per-call: pass max_bid_override >= amount on the tool call. Lower overrides refuse with reason: "override_too_low".
Operator-wide: set EBAY_MCP_ALLOW_HIGH_VALUE=1 in the MCP server's environment.
Human-in-the-loop confirm dialog. After the programmatic gates clear, the MCP pops a topmost, system-modal Yes/No dialog (Windows: MessageBoxW via ctypes; macOS/Linux: tkinter.messagebox) showing the tool, host, item ID, amount, currency, and quantity. The default button is NO, ESC cancels, and there is no auto-dismiss or timeout. Click YES to send the call to eBay; anything else returns a reason: "user_declined" refusal and no Trading call fires. There is intentionally no env-var bypass — tests stub the dialog directly. Production-host dialogs carry a *** PRODUCTION HOST — REAL MONEY *** header; sandbox dialogs say Sandbox host (no real money)..
Active-host visibility. Successful calls against default_host = "production" include a warning field in the response ("PRODUCTION HOST — this call committed real money on eBay."). server_info() flags the active host before any call.
No silent half-commits. No auth token cached → the underlying Trading API call raises before touching eBay, not mid-flight.
All money tools also surface eBay-side errors (insufficient bid, currency mismatch, listing ended, etc.) as TradingApiError with the parsed Errors block attached.
❌ Selling side (use eBay's Sell API directly for that — different shape entirely)
❌ Snipe-bidding with auto-trigger (one tool call = one bid, no scheduling)
❌ Multi-account: v0 is one user account per host config; add multi-account later if needed
Related MCP server: ebay-browse-mcp
Not yet on PyPI. From source:
git clone https://github.com/acato/ebay-mcp
cd ebay-mcp
uv sync
uv run ebay-mcpIf uv picks Microsoft Store Python (path under \WindowsApps\PythonSoftwareFoundation...) when creating the venv, the MCP runs fine from a terminal but fails to launch from GUI hosts like the Claude desktop app, IDE extensions, or scheduled tasks. You will see:
Unable to create process using "...\WindowsApps\PythonSoftwareFoundation.Python.3.12_...\python.exe"Pin uv to a non-Store interpreter — uv's managed Python is easiest:
uv python install 3.12
uv venv --python 3.12 --python-preference only-managed --clear
uv syncVerify: Get-Content .venv\pyvenv.cfg — the home = line should point under AppData\Roaming\uv\python\..., not \WindowsApps\.
Sandbox-first. Get your sandbox keyset from developer.ebay.com → Application Keysets → Sandbox. Copy examples/config.toml to ~/.config/ebay-mcp/config.toml:
default_host = "sandbox"
[hosts.sandbox]
app_id = "..." # SBX App ID (Client ID)
dev_id = "..." # Developer Account Dev ID
cert_id = "..." # SBX Cert ID (Client Secret) — env var preferred
redirect_uri = "https://localhost/oauth/callback"
# [hosts.production]
# app_id = "..."
# dev_id = "..."
# cert_id = "..."
# redirect_uri = "https://localhost/oauth/callback"Per-host env vars override file values:
EBAY_MCP_<HOST>_CERT_ID — overrides cert_id (recommended for production)
EBAY_MCP_<HOST>_APP_ID, EBAY_MCP_<HOST>_DEV_ID — overrides for completeness
User-level OAuth tokens cache to ~/.config/ebay-mcp/token-cache-<host>.json automatically after the manual authorization-code flow (see auth.py docs once Day 1b lands).
claude mcp add ebay-mcp -- uv run --directory /path/to/ebay-mcp ebay-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"ebay-mcp": {
"command": "C:\\Users\\you\\AppData\\Local\\Microsoft\\WinGet\\Links\\uv.exe",
"args": ["run", "--directory", "C:\\path\\to\\ebay-mcp", "ebay-mcp"]
}
}
}DESIGN.md — architecture, tool surface, safety patterns, OAuth flow
CONTRIBUTING.md — dev setup, sandbox testing, release process
Apache 2.0. See LICENSE and NOTICE.
"eBay" is a trademark of eBay Inc. This project is an independent integration with the standard eBay public APIs and is not affiliated with, endorsed by, or sponsored by eBay Inc.
Add an item to the authenticated user's watchlist.
Trading API AddToWatchList. Fully reversible — call
remove_from_watchlist with the same item_id to undo.
Args:
item_id: numeric eBay item ID (from search, get_item, etc.)
host: configured host. Defaults to default_host.
Returns:
dict with host, item_id, added: True, and
watch_list_count (total items in the watchlist after the
operation). Raises ValueError on empty item_id.
On eBay-side errors (item ended, already watched, etc.) the
Trading API raises TradingApiError with details.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral transparency burden. It explicitly states the operation is reversible, describes return values, and details error conditions (ValueError for empty item_id, TradingApiError for eBay-side errors). No contradictions 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?
The description is well-structured with a clear opening sentence, followed by details in a docstring format. It is informative but slightly verbose; could be tighter while retaining all 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?
Given the tool's simplicity (2 parameters, 1 required) and the presence of an output schema, the description covers parameters, returns, and errors adequately. However, it does not mention rate limits or authentication specifics beyond 'authenticated user'. Fairly 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?
The input schema has 0% description coverage, but the description adds meaningful semantics: 'item_id: numeric eBay item ID (from search, get_item, etc.)' and 'host: configured host. Defaults to default_host.' This provides context beyond the raw 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?
The description clearly states the tool's action: 'Add an item to the authenticated user's watchlist.' It uses specific verb and resource, and distinguishes from the sibling 'remove_from_watchlist' by mentioning reversibility.
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 gives clear context for using the tool (adding to watchlist) and mentions the undo operation via 'remove_from_watchlist'. However, it lacks explicit guidance on when not to use this tool versus other siblings like 'get_watchlist' or 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purchase a Buy It Now listing immediately at the listed price.
Trading API PlaceOffer with Action=Purchase. The buyer commits to pay the listing's BIN price; eBay creates the order on success.
PRODUCTION HOST WARNING: when the active host is "production", a successful call commits real money on eBay. Inspect server_info() or list_hosts() before committing.
Args: item_id: numeric eBay item ID. Get from search() or get_item(). confirm_amount: must equal the listing's Buy-It-Now price exactly. The repeated dollar amount is a safety gate against stale prices or typos. Look up the current price with get_item() right before calling. quantity: number of units to purchase (default 1). Multi-quantity BIN listings can have a per-buyer limit; eBay rejects with TradingApiError if violated. currency: ISO currency code matching the listing (default "USD"). max_bid_override: optional ceiling that authorizes amounts above the $500 per-call safety cap. Pass a value >= confirm_amount to bypass the cap for this call. host: configured host name. Defaults to default_host.
Returns: On success: dict with host, item_id, action="Purchase", amount, currency, quantity, placed=True, and (on production) a warning. On safety-gate failure: structured refusal payload. Raises ValueError / TradingApiError as in place_bid.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | ||
| confirm_amount | Yes | ||
| quantity | No | ||
| currency | No | USD | |
| max_bid_override | No | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses all behavioral traits: commits real money on production, safety gate with confirm_amount, eBay's rejection for quantity limits, and optional max_bid_override to bypass the safety cap. Returns and exceptions are detailed.
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 well-structured with clear sections (summary, implementation note, warning, parameters, returns). It is front-loaded with the core purpose. However, it is somewhat lengthy; the parameter descriptions could be slightly condensed, but still 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?
Given the complexity (6 params, production warnings, safety gates) and lack of annotations, the description is extremely complete. It covers purpose, usage, behavior, parameters, return values, and exceptions. No output schema exists, but return values are described.
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%, but the description adds detailed semantics for each of 6 parameters: item_id source, confirm_amount must equal BIN price, quantity default and limit warning, currency default, max_bid_override purpose, and host default. This fully compensates for the lack of 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?
The description clearly states 'Purchase a Buy It Now listing immediately at the listed price,' using a specific verb and resource. It contrasts with sibling tools like place_bid (for auctions) and make_best_offer.
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 warns about production host committing real money, advises inspecting server_info() before calling, and recommends looking up the current price with get_item() to prevent errors. It also notes multi-quantity limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finish OAuth2 user auth by exchanging the authorization code for tokens.
The code is the value of the code query parameter in the URL eBay
redirected to after start_user_auth's auth_url. Optionally pass state
to verify against what start_user_auth issued (CSRF defense).
Args:
code: the authorization code from eBay's redirect URL.
state: optional — the state value from the redirect URL. If provided,
must match what start_user_auth stored. Mismatch returns a
structured refusal payload.
host: which configured host to authenticate against. Defaults to
config's default_host. Must match the host used in
start_user_auth.
Returns: On success: {host, authenticated: true, access_expires_at, refresh_expires_at} On state mismatch: {refused: true, reason: "state_mismatch", host, message: ...}
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| state | No | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format for success and failure (state mismatch refusal payload), and mentions the effect of the optional state parameter. It does not cover rate limits or side effects like token storage, but the main behavioral aspects are covered.
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 concise with a clear introductory sentence followed by structured args and returns sections. Every sentence adds value, and the front-loaded summary immediately conveys the tool's purpose.
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 description covers the primary use case, parameters, and return values. It includes failure cases for state mismatch. However, it could mention other potential errors (e.g., expired code) or more detail about token handling. Still, given the tool's simplicity, it is largely 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?
The input schema has 0% description coverage, but the description thoroughly explains each parameter: 'code' is from eBay's redirect URL, 'state' is optional for CSRF with mismatch handling, and 'host' defaults to config's default. This adds significant meaning beyond the bare 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?
The description clearly states the tool completes OAuth2 user auth by exchanging an authorization code for tokens. It uses a specific verb-resource combination and distinguishes itself from its sibling 'start_user_auth' by referencing the previous step.
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 mentions when to use this tool (after start_user_auth's auth_url redirect) and explains optional state verification for CSRF. It implicitly suggests not to use it before starting auth. However, it does not explicitly list when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return auctions where the user has a currently-active bid.
Trading API GetMyeBayBuying.BidList. Includes both winning and outbid items still in their bidding period.
Same response shape as get_watchlist. Empty hits + total=0 means
you have no active bids.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool returns active bids including winning and outbid items, and explains the response shape and empty result meaning. It does not mention authentication or rate limits, but for a read-only tool this is adequate.
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 concise, with three sentences. The key purpose is front-loaded, and every sentence adds value. There is no redundancy or unnecessary detail.
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 description covers the basic behavior and response shape, especially since an output schema exists. However, the lack of parameter documentation is a significant gap, and the description does not fully leverage sibling tools to differentiate usage contexts.
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 0% description coverage for 3 parameters (limit, offset, host), and the description does not explain any of them. The description adds no meaning beyond the raw parameter names and defaults, providing no guidance on what these parameters control.
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 'Return auctions where the user has a currently-active bid' and provides specific details about the eBay API source and inclusion criteria. It distinguishes well from siblings like get_watchlist and get_won_items.
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 mentions the response shape is the same as get_watchlist and explains how to interpret empty results, but does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for a single eBay item by ID.
Args:
item_id: the eBay item ID (e.g., "v1|353528728623|0"). Get these from
search() results.
marketplace: eBay marketplace ID (default "EBAY_US").
host: which configured host to use. Defaults to config's default_host.
Returns: Full item dict including description, shipping options, seller details, return terms, item location, and the standard summary fields. If the item doesn't exist or has ended, returns {"item_id": item_id, "host": host, "missing": true}.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | ||
| marketplace | No | EBAY_US | |
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that if the item doesn't exist or has ended, the tool returns a missing flag. It also implies a read-only operation, which is consistent with the lack of destructive hints.
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 fairly concise, using a docstring format with Args and Returns sections. It could be slightly tighter, but it is well-organized and front-loads the core purpose.
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 description covers the return value with a full dict including various fields, and handles the missing case. Given the presence of an output schema (not shown), this is complete for a retrieval tool of moderate complexity.
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 0% schema description coverage, the description compensates by explaining the source of item_id, the default for marketplace, and the host parameter. This adds significant value beyond the raw 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?
The description clearly states it fetches full details for a single eBay item by ID, using a specific verb and resource. It distinguishes from sibling tools like search, which returns summaries, and other action 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?
The description explains how to obtain item_id from search() results and notes defaults for marketplace and host. It provides clear context but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return auctions where the user bid but did not win.
Trading API GetMyeBayBuying.LostList. Default lookback ~30 days; older items roll off.
Same response shape as get_watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is read-only (returns lost items) and specifies the default lookback and data retention behavior. However, it does not mention authentication requirements, rate limits, error handling, or pagination behavior, leaving gaps in 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 concise, consisting of three short sentences that front-load the main purpose. It avoids unnecessary detail and is well-structured for quick comprehension.
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 presence of an output schema reduces the need to describe return values. However, with 0% parameter description coverage and the tool having three siblings, the description could be more complete by explaining pagination parameters and offering comparisons to related tools. As it stands, it is minimally 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?
The input schema has three parameters (limit, offset, host) with no descriptions (0% schema coverage). The tool description does not explain what these parameters do or how to use them. This leaves the agent without guidance on parameter semantics, which is a significant gap.
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 returns auctions where the user bid but did not win, which is a specific verb+resource combination. It also references the underlying API and distinguishes itself by mentioning the same response shape as 'get_watchlist', differentiating it from siblings like 'get_won_items' or 'get_active_bids'.
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 provides context such as the default lookback period of ~30 days and that older items roll off, but it does not explicitly explain when to use this tool versus alternatives like 'get_active_bids' or 'search'. The usage is implied but lacks direct guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the authenticated user's watched items.
Uses Trading API GetMyeBayBuying with the WatchList container.
Requires that the user has authenticated via start_user_auth +
complete_user_auth for the chosen host.
Args: limit: items per page (1-200). Default 100. offset: pagination offset. Trading API pages from 1; we translate. host: configured host name. Defaults to default_host.
Returns:
dict with host, container, total, limit, offset, and
hits (a list of item summaries: item_id, title, price, currency,
ends_at, bid_count, seller, web_url, listing_type,
quantity_available).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It reveals the underlying API (GetMyeBayBuying with WatchList container) and explains pagination translation. It also mandates prior authentication flow, providing transparency beyond a simple 'get' statement.
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 well-structured with Args and Returns sections, front-loaded with the main purpose. While verbose, every sentence adds value and the docstring format is appropriate for the complexity.
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 has only 3 parameters and an output schema, the description covers authentication, pagination, param details, and return structure. It could mention error handling or default host behavior, but it is largely 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?
The description adds detail not in the schema: limit range (1-200), offset behavior (Trading API pages from 1), host defaulting to default_host. It also documents the return structure comprehensively, exceeding the 0% schema coverage baseline.
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 returns the authenticated user's watched items, using a specific API call. This distinguishes it from sibling tools like add_to_watchlist or remove_from_watchlist.
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?
While the description indicates the tool is for retrieving watched items, it does not explicitly compare with siblings or state when to use this vs. other retrieval tools like get_active_bids or get_won_items. No exclusion criteria or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return items the user won at auction or bought via Buy It Now.
Trading API GetMyeBayBuying.WonList. This is your effective "purchase history" for the eBay-native default lookback window (eBay shows the last 30 days by default; older items roll off the WonList container).
Same response shape as get_watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It addresses the lookback window and that older items are dropped, but lacks details on authentication requirements, pagination behavior, or error conditions. The mention of same response shape as get_watchlist is helpful but incomplete.
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 and reasonably concise, covering purpose, underlying API, and a note on response shape. It is front-loaded with the main purpose. Minor improvement could be more structured if parameters were included.
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 that an output schema exists, the description does not need to detail return values. However, it omits parameter documentation and lacks guidance on authentication and pagination. The lookback window and API source are good context, but overall completeness is moderate for a tool with three 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 description coverage is 0%, and the description does not mention or explain any of the three parameters (limit, offset, host). It adds no semantic meaning beyond the parameter names, leaving the agent to infer usage from defaults.
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 it returns items won or bought via Buy It Now, specifying it as the effective purchase history and distinguishing from siblings like get_watchlist and get_lost_items. It also identifies the underlying API (Trading API GetMyeBayBuying.WonList).
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 provides context on the default lookback window and that older items roll off, which helps understand when results are available. It also notes the response shape is the same as get_watchlist. However, it does not explicitly state when to use this tool over alternatives like get_active_bids or get_lost_items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every configured host with its status (default flag and cert availability).
Useful for diagnosing why a tool call against a particular host might fail before you make the call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the tool lists hosts with status fields, which is adequate for a simple read operation. However, it omits details like idempotency, performance, or any side effects, remaining generic.
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?
Two concise sentences: first defines purpose, second provides usage context. No redundant or vague language.
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 (no parameters, output schema exists), the description covers the essential information: what it lists and the use case. It could mention that it returns all hosts without filters or pagination, but is otherwise 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?
The tool has no parameters, so schema coverage is 100% by default. Baseline for zero parameters is 4. The description adds no parameter information since none exist.
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 lists every configured host with its status, including default flag and cert availability. This is a specific verb-resource combination and is distinct from sibling tools like server_info or search.
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 suggests using the tool to diagnose potential failures before making a tool call against a particular host. It provides a clear use case but does not mention when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a Best Offer on a listing that has Best Offer enabled.
Trading API PlaceOffer with Action=BestOffer. The seller can accept, counter, or decline; this call only places the offer.
PRODUCTION HOST WARNING: when the active host is "production" and the seller accepts, the offer becomes a binding sale at the offer amount.
Args:
item_id: numeric eBay item ID. Must have Best Offer enabled —
check buying_options on get_item() output for "BEST_OFFER".
offer_amount: the price the buyer offers, in currency. Must be
> 0. Many sellers configure auto-decline below a threshold.
confirm_amount: must equal offer_amount exactly. Safety gate.
quantity: number of units the offer covers (default 1).
currency: ISO currency code matching the listing (default "USD").
max_bid_override: optional ceiling that authorizes offer amounts
above the $500 per-call safety cap. Pass a value >=
offer_amount to bypass.
host: configured host name. Defaults to default_host.
Returns: On success: dict with host, item_id, action="BestOffer", amount, currency, quantity, placed=True, optionally best_offer_id (for follow-up via Trading GetBestOffer / Accept flows), and (on production) a warning. On safety-gate failure: structured refusal payload. Raises ValueError / TradingApiError as in place_bid.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | ||
| offer_amount | Yes | ||
| confirm_amount | Yes | ||
| quantity | No | ||
| currency | No | USD | |
| max_bid_override | No | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: binding sale on production, safety gates (confirm_amount must equal offer_amount, max_bid_override for amounts over $500), structured refusal payload, and exceptions. It also notes that the seller can accept/counter/decline but this call only places the offer.
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 well-structured: a clear one-sentence purpose, a production warning, then Args and Returns sections. Every sentence adds value with 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?
For a complex tool with 7 parameters and no annotations, the description covers all necessary context: prerequisites, return structure, safety mechanisms, and follow-up possibilities (best_offer_id). The presence of an output schema is noted but the description still explains key return fields.
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%, so the description provides all parameter meaning. It explains each parameter's purpose, constraints (e.g., offer_amount must be > 0, confirm_amount must equal offer_amount), defaults, and hints about auto-decline thresholds and safety caps.
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 'Submit a Best Offer on a listing that has Best Offer enabled' and mentions the underlying API call (Trading API PlaceOffer with Action=BestOffer). This distinguishes it from siblings like place_bid and buy_now, which handle different purchase flows.
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?
Includes explicit guidance: 'Must have Best Offer enabled — check buying_options on get_item() output for "BEST_OFFER".' Also warns about the binding nature on production. However, it does not explicitly list when to avoid this tool or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a proxy bid on an eBay auction.
Trading API PlaceOffer with Action=Bid. eBay treats max_bid_amount as a proxy ceiling — it bids the minimum needed to outbid the current high bidder, and continues raising up to max_bid_amount as competing bids come in.
PRODUCTION HOST WARNING: when the active host is "production", a successful call commits real money on eBay. Inspect server_info() or list_hosts() before committing.
Args:
item_id: numeric eBay item ID. Get from search() or get_item().
max_bid_amount: the proxy bid ceiling in currency. Must be > 0.
confirm_amount: must equal max_bid_amount exactly. The repeated
dollar amount is a safety gate against typos.
quantity: number of units (default 1; only relevant for
multi-quantity auctions).
currency: ISO currency code matching the listing (default "USD").
Must match the listing's currency or eBay refuses.
max_bid_override: optional ceiling that authorizes amounts above
the $500 per-call safety cap. Pass a value >= max_bid_amount
to bypass the cap for this call. Lower values are refused.
host: configured host name. Defaults to default_host. The active
host (sandbox vs production) is surfaced in the response.
Returns: On success: dict with host, item_id, action="Bid", amount, currency, placed=True, current_price, minimum_to_outbid, high_bidder, and (on production) a warning field. On safety-gate failure: structured refusal payload (refused=True, reason, message, plus the offending values). Raises ValueError on empty item_id, non-positive amounts, etc. On eBay-side errors (listing ended, currency mismatch, insufficient bid, etc.) raises TradingApiError.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | ||
| max_bid_amount | Yes | ||
| confirm_amount | Yes | ||
| quantity | No | ||
| currency | No | USD | |
| max_bid_override | No | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Thoroughly explains proxy bid mechanics, safety gates, host differentiation, error handling, and return values.
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 purpose first, followed by mechanism, warnings, parameter list, and return values. Informative without excessive verbosity.
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: purpose, mechanism, parameters, return values, errors, safety, and host context. Refers to sibling tools for host checking. Complete for a complex bidding 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 0%, but description explains each parameter with purpose, constraints, and interactions (e.g., confirm_amount as safety gate, max_bid_override for exceeding cap). Adds significant meaning beyond schema types.
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 'Place a proxy bid on an eBay auction', using specific verb and resource. Distinguishes from sibling tools like buy_now and make_best_offer.
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?
Provides clear context of proxy bidding and host safety, but lacks explicit when-to-use vs alternatives. Sibling context makes scope clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an item from the authenticated user's watchlist.
Trading API RemoveFromWatchList. Fully reversible — call
add_to_watchlist with the same item_id to undo.
Args: item_id: numeric eBay item ID currently on the watchlist. host: configured host. Defaults to default_host.
Returns:
dict with host, item_id, removed: True, and
watch_list_count (total items in the watchlist after the
operation). Raises ValueError on empty item_id. eBay-side
errors (item not on watchlist, etc.) surface as TradingApiError.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | ||
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully covers behavior: return structure, error handling (ValueError, TradingApiError), and reversibility. Discloses that item must be currently on watchlist.
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 labeled sections (description, reversibility, args, returns, errors). Each sentence adds value, no 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?
Output schema exists and description details return dict fields. Covers all 2 parameters, error cases, and reversibility. Complete for this tool's purpose.
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?
Despite 0% schema description coverage, the description clearly explains item_id (numeric eBay item ID on watchlist) and host (configured host with default). Adds meaning beyond schema field names.
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 'Remove an item from the authenticated user's watchlist.' Provides specific verb (remove) and resource (watchlist), distinguishing it from siblings like add_to_watchlist.
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 mentions reversibility via add_to_watchlist and describes when to use. Does not explicitly state when not to use, but provides sufficient context for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search eBay items via the Browse API.
Args:
query: keyword search string. Required.
category_id: numeric eBay category ID to restrict the search.
condition: one of NEW, LIKE_NEW, NEW_OTHER, USED_EXCELLENT,
USED_VERY_GOOD, USED_GOOD, USED_ACCEPTABLE, FOR_PARTS_OR_NOT_WORKING,
MANUFACTURER_REFURBISHED, CERTIFIED_REFURBISHED, or several other
refurbished tiers. Case-sensitive.
min_price: minimum item price (in currency).
max_price: maximum item price (in currency).
currency: ISO currency code for the price filter (default "USD").
sort: one of "best_match" (default), "price_asc", "price_desc",
"newly_listed", "ending_soonest".
limit: number of hits per page. Default 20, hard cap 200.
offset: pagination offset.
marketplace: eBay marketplace ID (default "EBAY_US"). Other examples:
"EBAY_GB", "EBAY_DE", "EBAY_IT".
host: which configured host to use ("sandbox" or "production"). If
omitted, uses the config's default_host.
Returns: dict with: - host: which host was actually targeted - total: total matching items per eBay - limit, offset, next_offset (None when there's no next page) - hits: list of item summaries (item_id, title, price, currency, condition, seller, image_url, ends_at, buying_options, web_url, bid_count if applicable)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| category_id | No | ||
| condition | No | ||
| min_price | No | ||
| max_price | No | ||
| currency | No | USD | |
| sort | No | best_match | |
| limit | No | ||
| offset | No | ||
| marketplace | No | EBAY_US | |
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses pagination behavior (limit, offset, next_offset), return structure, and default values. However, it does not mention rate limits, authentication requirements, or error handling.
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 well-structured with Args and Returns sections, front-loading the purpose. It is slightly lengthy but every sentence adds value. A minor improvement could be trimming 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?
Given the complexity of 11 parameters and no output schema, the description is comprehensive. It explains all parameters, return values, and defaults, covering everything an agent needs to invoke the tool correctly.
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%, but the description provides detailed semantics for all 11 parameters: required status, values for condition and sort, defaults, and examples like marketplace codes. This fully compensates for the lack of 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?
The description clearly states 'Search eBay items via the Browse API', which is a specific verb+resource. It distinguishes from sibling tools like get_item and get_watchlist by focusing on searching across items.
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 usage for searching items but provides no explicit guidance on when to use this tool versus alternatives like get_item or when not to use it. No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return server version, active host, and configuration locations.
The active_host field reflects what default_host is set to (or what
would be used when a tool call omits the host parameter). When set to
"production", the response includes a warning field — real money is
at stake on bid/buy operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explains important behavioral traits: the meaning of active_host (reflects default_host) and that a warning field appears in production mode. It does not mention if it's read-only, but this is implied.
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 concise (two paragraphs) with no wasted words. The main purpose is front-loaded, and the additional details are relevant and well-structured.
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 (no parameters, output schema exists), the description covers key behaviors and field meanings. It could elaborate on 'configuration locations' but is still fairly 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?
There are zero parameters, and schema coverage is 100%. The description adds value by explaining the behavior of the active_host field and the warning condition, which goes beyond the empty 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?
The description clearly states the tool returns server version, active host, and configuration locations. It uses specific verbs and resource names, and is distinct from sibling tools which are auction actions.
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 does not explicitly state when to use this tool vs siblings, but its unique purpose as a server info tool is clear. No alternatives are mentioned, but the context signals indicate it is a standalone info endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Begin OAuth2 user authentication for buyer-side eBay operations.
Watchlist, MyeBay reads, bidding, and buying all require a user token.
This tool returns an auth_url for you (the human) to open in a browser.
After signing in and granting permissions, eBay redirects to the
configured redirect_uri with a code query parameter — pass that to
complete_user_auth to finalize.
Most workflows only run this once per host; tokens persist 18 months and auto-refresh.
Args:
host: which configured host to authenticate against. Defaults to
config's default_host.
Returns:
dict with host, auth_url, state, and instructions. The
auth_url is what the human needs to open; the state is
round-tripped to verify the callback genuinely came from this flow.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it returns an auth_url for human interaction, explains the redirect flow, and mentions token persistence (18 months, auto-refresh). This is comprehensive.
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 well-structured, with clear sections, bullet points for args/returns, and no wasted words. Front-loaded with purpose.
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 output schema exists, the description adequately explains return values and provides complete usage context, including token lifecycle and workflow steps. No gaps.
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 schema has 0% description coverage, but the description explains the 'host' parameter meaning (which configured host, defaults to config's default_host). This adds value 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?
The description clearly states it begins OAuth2 user authentication for buyer-side eBay operations, using specific verbs and resource. It distinguishes from siblings by referencing 'complete_user_auth' and outlining the workflow.
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?
It explicitly says when to use this tool (for operations requiring user token) and notes that most workflows run once per host. It lacks explicit 'when-not' or alternative tool names beyond the context, hence not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.5.0add_to_watchlistbuy_nowcomplete_user_authget_active_bidsget_itemget_lost_itemsget_watchlistget_won_itemsmake_best_offerplace_bidremove_from_watchlistsearchstart_user_authv0.0.0list_hostsserver_infoEach tool targets a distinct operation (search, watchlist CRUD, bidding, buying, auth, etc.). Overlapping tools like get_watchlist, get_active_bids, get_lost_items, get_won_items are clearly distinguished by state and documented. No ambiguity.
All tool names use lowercase with underscores and follow a consistent verb_noun pattern (e.g., add_to_watchlist, get_item, place_bid, buy_now, start_user_auth). No mixed conventions or cryptic names.
15 tools is well-scoped for the server's purpose (eBay buyer operations). Every tool covers a necessary function without redundancy, and the count is within the ideal 3-15 range.
Covers all core buyer actions: search, item details, authentication, watchlist, bidding, buying (BIN and Best Offer), and purchase history (won/lost/active). Minor gaps exist (e.g., no tool for seller messaging or order cancellation), but the primary workflow is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Product Management
Remote MCP for Living Stack offer discovery and buyer-authorized checkout preparation.
MCP server for the BuyerSense API. Get buyer signals from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/acato/ebay-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
