This server provides MCP tools to search for deals on Japanese marketplaces via Doorzo, monitor keywords for price drops, and manage alerts.
Search: doorzo_search searches across 9 shops (Mercari, Yahoo Auctions, Rakuten, Amazon Japan, Rakuma, PayPay Flea, PayPay Mall, Lashinbang, SNKRDUNK) with filters: max price (JPY), min discount %, shop restrictions, stock status, and sort order.
Trending: doorzo_hot_searches returns current hot keywords.
Exchange rates: doorzo_exchange_rate gets the JPY to any currency rate.
Manage monitors: doorzo_monitor_add creates a monitor with name, keyword, price ceiling (JPY), optional shop/discount filters, and notification toggle. doorzo_monitor_remove deletes by ID. doorzo_monitor_list lists all monitors with IDs, keywords, price ceilings, and last-check stats.
Check monitors: doorzo_check_monitors checks for new deals (optionally for a specific monitor) and can run continuously every 60s for a set number of minutes, firing notifications and logging results.
Click on "Deploy 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., "@Doorzo Deal Monitor find me a good deal on a Nintendo Switch under ¥25,000"
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.
A tool that finds good deals on Japanese shopping sites and alerts you when something worth buying shows up.
It searches doorzo.com — a proxy-shopping service that combines 9 Japanese marketplaces: Mercari, Rakuma, PayPay Flea, PayPay Mall, Rakuten, Yahoo Auctions, Amazon Japan, Lashinbang, and SNKRDUNK.
No AI needed to use it. No browser automation or scraping either — it talks to doorzo's own API directly.
Search for a keyword (e.g. マリオパーティ or nintendo switch) across all 9 marketplaces at once.
Filter by price — set a ceiling in Australian dollars in the web UI.
Spot discounts — shows the list price vs. the sale price and the % off.
Monitor keywords — tell it "alert me when a Mario Party game appears for under A$30". It checks in the background and notifies you (macOS notification + a log file).
Trending searches — see what people are hunting for right now.
Live AUD prices — the web UI converts Doorzo's JPY prices and price ceilings using Doorzo's current AUD rate.
Open via Doorzo — product and alert links stay inside Doorzo instead of sending you to the underlying marketplace.
Choose how to buy — narrow results to Buy It Now listings or auctions.
Avoid junk listings — hide likely junk, broken, untested, or parts-only items by default; show or isolate them when wanted. Flagged results carry a clear JUNK / PARTS label and reason.
Related MCP server: mercari-jp-mcp
Web UI | AI (MCP) | |
Who uses it | You, in a browser | An AI assistant like Claude Code |
How it looks | A website at | Tools the AI can call |
Best for | Browsing, adding monitors, checking alerts | Asking the AI to find/watch deals for you |
Both share the same data and the same monitors.
1. Install. You need Python 3.11+ and uv (a Python tool installer).
git clone https://github.com/TESTYEE-09/DoorzoMCP.git
cd DoorzoMCP
uv sync2. Start the web UI.
uv run doorzo-web3. Open your browser at http://127.0.0.1:8756 — done.
Search something, or add a monitor: give it a name, a keyword, and a max price. Click Check all monitors to check for new matches right now. New matches fire a macOS notification and appear in the Alerts list.
The web UI displays and accepts prices in AUD. Internally, monitor ceilings are converted to JPY so the web UI and MCP server can continue sharing the same backward-compatible state. Product links open through Doorzo, where you can review or purchase the listing using Doorzo's proxy-shopping flow.
Your monitors and alerts are stored in ~/.doorzo-mcp/ and survive restarts.
Set DOORZO_STATE_DIR before starting either service only if you want to keep
that state somewhere else.
If you use Claude Code (or another MCP-compatible assistant), you can give it access to the same search and monitors:
claude mcp add doorzo-deals -- uv run --directory /path/to/DoorzoMCP doorzo-mcpThe AI then has these tools: doorzo_search, doorzo_hot_searches, doorzo_exchange_rate, doorzo_monitor_add, doorzo_monitor_remove, doorzo_monitor_list, and doorzo_check_monitors. Example: "add a monitor for a Mario Party game under ¥3,000 and check it now" — it will do that and tell you what it found.
The MCP tool parameters and returned price fields remain in JPY. This keeps the public tool contract stable for existing agents; AUD conversion is a web UI feature.
doorzo_mcp/
client.py # talks to doorzo.com's API
deals.py # decides what counts as a deal
store.py # saves your monitors and alerts (~/.doorzo-mcp)
notify.py # macOS notifications
server.py # the AI (MCP) tools
web.py # the website and its API
static/ # the web page itself (single file, no build step)Prices are before proxy fees. You still pay doorzo's service fee and international shipping. The tool finds cheap listings.
AUD amounts are estimates. Doorzo's live rate is used, and the final amount may differ when Doorzo processes the purchase.
Condition text comes from the sites in Chinese; this tool translates it to English (unknown labels pass through as-is).
The API could change. doorzo.com is an unaffiliated third party; this project uses its internal API with no authentication, so it may break if they change things or add bot protection.
MIT licensed. Use at your own risk. Not affiliated with or endorsed by doorzo.com.
Check monitors for NEW deals; notify and log matches.
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | No | check only this monitor (default: all). | |
| watch_minutes | No | if > 0, keep re-checking every 60s until this many minutes have elapsed (long-running call). Default 0 = one shot. |
| 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 the burden of behavioral disclosure. It mentions 'notify and log matches,' which are important side effects, but leaves specifics vague (e.g., how notification occurs, what logging entails, persistence, external side effects). With no annotations, this is minimally adequate but lacks depth.
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 redundant words. It efficiently conveys the core action and outcome ('Check monitors for NEW deals; notify and log matches'), making it easy to parse and ideal for quick agent scanning.
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 tool has low complexity, complete parameter schemas, and an output schema, which reduces the need for extensive description. However, key behavioral aspects are ambiguous: what counts as 'NEW deals,' how notification is performed, and the exact logging behavior are unspecified. These gaps matter for an agent deciding whether this tool fits the user's request.
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%, with both parameters (monitor_id and watch_minutes) clearly described in the schema. The description itself adds no parameter-specific detail, which is acceptable since the schema already provides full semantics. Baseline of 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 uses a specific verb ('Check') and resource ('monitors for NEW deals'), clearly indicating the tool's core function. It distinguishes from sibling tools like doorzo_monitor_list (which lists monitors) and doorzo_search (which searches deals) by focusing on checking monitors for new matches, though it does not explicitly name these alternatives.
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 when to use the tool (when you want to check monitors for new deals) but provides no explicit guidance on when not to use it or how it compares to alternatives. There are no exclusions or alternative tool references, leaving the decision partially to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the JPY -> currency exchange rate doorzo uses.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | ISO 4217 code, e.g. "AUD", "USD", "CNY". | AUD |
| 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 the full burden of behavioral disclosure. It only says 'Return' which implies a read operation, but it does not explain rate freshness, unsupported currency behavior, or error handling. This is a significant gap for a tool with zero annotation coverage.
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, focused sentence that front-loads the action and resource. It is concise, with no wasted words, making it easy to parse.
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 read-only tool with one parameter and an output schema, the description covers the core operation sufficiently. However, it omits details about how the rate is determined or any restrictions, which slightly reduces 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?
The input schema already fully documents the 'currency' parameter with ISO 4217 code examples and a default value. The description adds no additional meaning beyond the schema, so the baseline of 3 applies here.
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 verb 'Return' and the resource 'the JPY -> currency exchange rate doorzo uses', making the purpose specific and unambiguous. It distinguishes itself from sibling tools which focus on monitors and search, so there is no confusion.
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 the tool is used to retrieve Doorzo's JPY conversion rate for a given currency. Since there are no sibling tools for exchange rates, the context is clear, but no explicit alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return doorzo's current hot/trending search keywords.
| 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 the burden. The verb 'Return' implies a read-only operation, but no specifics about caching, data freshness, rate limits, or return structure are mentioned. The description adds minimal behavioral context beyond the tool name.
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 that is front-loaded with the action and resource. There is no redundant information 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?
Given the tool's simplicity (no parameters, no nested objects), the description is complete. An output schema exists to document the return format, so the description does not need to explain it further. The minimal description suffices for a tool of this 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?
The tool has zero parameters, and schema coverage is 100% (vacuously). The description does not need to add parameter meaning since there are none, matching the baseline of 4 for zero-parameter tools.
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 function with a specific verb ('Return') and resource ('doorzo's current hot/trending search keywords'). It distinguishes itself from sibling tools like doorzo_search and doorzo_monitor_list, which serve different purposes.
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 retrieving trending keywords but does not explicitly state when to use it versus alternatives or provide exclusions. Context is clear but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a deal monitor: alert when items match keyword at/below price.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | monitor label (e.g. "mario party"). | |
| shops | No | optional shop restriction. | |
| keyword | Yes | search term. | |
| max_price_jpy | Yes | price ceiling (JPY); items above it never alert. | |
| notify_enabled | No | send macOS notifications on new matches (default true). | |
| min_discount_pct | No | require at least this % off origin price when an origin price exists; without origin data the item is skipped. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It reveals the core alerting behavior (matching keyword and price) but omits important side effects such as notification delivery, persistence of the monitor, or behavior when existing monitors share the same name. The schema descriptions fill some gaps, but the main description itself is thin.
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, focused sentence that is front-loaded with the primary action. Every word contributes meaning, and there is no fluff or repetition.
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 tool has 6 parameters and an output schema, but the description is quite brief. While the schema covers parameter details, the description does not explain the overall workflow (e.g., that the monitor will immediately start watching, that notifications only work on macOS, or how monitors are managed after creation). It provides the core idea but lacks sufficient context for a user to fully understand the tool's place in the broader system.
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%, so the baseline is 3. The description adds minimal context by linking 'keyword' and 'at/below price' to the corresponding parameters, but it does not elaborate on parameter meanings beyond what the schema already 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?
The description clearly states the tool's function: 'Add a deal monitor: alert when items match keyword at/below price.' The verb 'Add' specifies the action, and the resource and condition ('deal monitor', 'keyword at/below price') are unambiguous. It also distinguishes from sibling tools like remove, list, and search by focusing on creation and alerting.
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 usage context is implied: it is used to create a new deal monitor, whereas siblings cover removal, listing, and checking. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all monitors (id, keyword, price ceiling, last check stats).
| 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 the full burden. It states 'List' which implies a read-only operation, but it does not explicitly disclose safety, auth needs, or side effects. It does add transparency about output fields.
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 with the verb, and includes essential detail without any fluff. Every word earns its place.
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 parameterless list tool with an output schema, the description is largely complete. It covers the main purpose and fields, but does not mention ordering, pagination, or authentication requirements, which could be relevant.
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 no parameters, so the baseline is 4. The description adds value by listing output fields, but since there are no params, it does not need to compensate for schema gaps.
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 verb 'List' and the resource 'monitors', and specifies the exact fields returned (id, keyword, price ceiling, last check stats). This distinguishes it from sibling tools like add, remove, and check.
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?
Usage is implied: you use this to see all monitors. However, it does not explicitly mention when not to use it or suggest alternatives among the sibling tools, such as doorzo_check_monitors for checking statuses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a monitor by id (also drops its seen-item state).
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 voluntarily surfaces a non-obvious side effect: 'also drops its seen-item state.' This goes beyond a generic 'removes item' statement and warns the agent about state loss, which is valuable.
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, tightly packed sentence that includes both the core action and a key side effect. There is no fluff or repetition, making it an excellent example of parsimonious documentation.
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 remove tool with one parameter and an output schema, the description covers the essential behavior and an important side effect. It does not explain error handling or edge cases, but the tool's low complexity means this is an acceptable level of 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?
The schema provides no description for monitor_id and overall coverage is 0%. The description confirms that the parameter is the monitor's identifier ('Remove a monitor by id'), but it does not provide format, source, or examples. The property name itself is self-explanatory, but the description adds minimal extra meaning.
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 'Remove a monitor by id' uses a specific verb ('Remove') and resource ('monitor'), clearly distinguishing it from sibling tools like doorzo_monitor_add and doorzo_monitor_list. The additional note about dropping seen-item state further clarifies the scope of the operation.
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 context is unambiguous: this tool is for removing a monitor, and the 'by id' phrasing implies that one must first obtain the id from a list or search. There is no explicit when-not-to-use or alternative suggestion, but the simplicity of the tool makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search doorzo.com across Japanese shops for a keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | "recommended" (default), "price_asc", or "price_desc". | recommended |
| limit | No | max items to return (default 20). | |
| shops | No | restrict to shop names, e.g. ["mercari", "yahoo_auction"]. | |
| keyword | Yes | search term (Japanese or English; the API translates). | |
| max_price_jpy | No | only items at or below this price (JPY). | |
| only_in_stock | No | exclude sold-out items (default true). | |
| min_discount_pct | No | require at least this % off the origin price. |
| 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 the behavioral disclosure burden. It states the core behavior (search across Japanese shops) but does not reveal potential nuances like filtering, sorting defaults, or that the keyword can be translated. The schema covers parameters, but the description adds little beyond the basic 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?
The description is a single sentence that is direct and front-loaded. It avoids unnecessary words and clearly communicates the tool's essence, making it highly 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?
While the schema and output schema provide extensive detail, the description lacks contextual guidance such as when to use the tool, what types of results to expect, or any limitations. Given the tool's moderate complexity and absence of annotations, a slightly more informative description would improve completeness. However, the rich schema compensates partially.
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%, so the baseline is 3. The description only mentions 'a keyword', which duplicates the schema's 'keyword' parameter without adding new meaning. All parameters are adequately documented in the schema, so the description adds no extra semantic value.
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 ('search') and resource ('doorzo.com across Japanese shops') and clearly states the input ('a keyword'). This distinguishes it from sibling tools like doorzo_monitor_add and doorzo_hot_searches, which are about monitoring and trends.
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 across Japanese shops, but does not explicitly state when to use it versus alternatives (e.g., monitoring tools). No exclusions or alternative tool references are mentioned, so guidance is limited to the general purpose.
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.
v1.0.0doorzo_check_monitorsdoorzo_exchange_ratedoorzo_hot_searchesdoorzo_monitor_adddoorzo_monitor_listdoorzo_monitor_removedoorzo_searchScored across 7 tools
Each tool targets a distinct function: monitor lifecycle (add/remove/list/check), search, trends, and exchange rate. There is no overlap or ambiguity between them.
All tools share the 'doorzo_' prefix, but the verb_noun pattern is inconsistent: 'monitor_add' and 'monitor_remove' place noun first, while 'check_monitors' puts verb first, and 'search'/'exchange_rate' are not verb_noun at all. Still readable and predictable.
Seven tools is well-scoped for a deal monitor service, covering management, execution, and auxiliary queries without bloat.
Core monitor lifecycle is complete (add, remove, list, check), and search/rate tools support the workflow. Missing an update/price change operation is a minor gap that agents can work around by removing and re-adding.
MCP server aggregating developer infrastructure deals, free tiers, and startup programs
An MCP server that integrates with Discord to provide AI-powered features.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
