This is an MCP server for tracking retail product prices (starting with UNIQLO Taiwan), backed by local SQLite storage and a plugin-based store adapter architecture.
Core capabilities:
Add a product (add_product): Register a product URL for tracking, with optional name, target price, sale notification preference, and specific sizes to watch.
List products (list_products): View all tracked products, with an option to filter by active-only status.
Check a product (check_product): Fetch the latest price/status for a specific product and record results in price history and event logs.
Check all products (check_all): Run price checks across all active tracked products at once — ideal for scheduled/cron jobs.
View price history (price_history): Retrieve historical price data for a product, configurable by number of days (default 90).
Remove a product (remove_product): Deactivate tracking for a product without permanently deleting its history.
Resolve a product (resolve_product): Search store adapters for product candidates matching a text query (e.g., name, product code, or OCR-extracted text) — useful for discovering trackable URLs before adding them.
OCR-assisted resolution (resolve_product_from_image): Optionally run OCR on a local price label image to extract text and resolve product candidates (requires OCR extra).
Track retail product prices for UNIQLO Taiwan, allowing users to add products, check prices, and monitor price 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., "@retail-price-tracker-mcp Add the UNIQLO AIRism cotton T-shirt to my tracked products"
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.
retail-price-tracker-mcp is an open-source Model Context Protocol (MCP) server for tracking retail product prices. It is designed to work well with Hermes Agent, Claude Desktop, Cursor, and any other MCP client.
The first adapter target is UNIQLO Taiwan. The project is intentionally adapter-based so future stores such as GU, MUJI, momo, or booksellers can be added without rewriting the tracking core.
Status: early scaffold / pre-alpha. The current UNIQLO adapter is conservative: it parses supported URLs and records products, but it does not fabricate live prices when a reliable public API is not available.
MCP tools for adding, listing, checking, and removing tracked products.
SQLite persistence for products, price history, and detected events.
Store adapter architecture.
UNIQLO Taiwan adapter with search-based current price lookup and safe failure modes.
Generic static adapter for tests and local demonstrations.
Optional, local OCR-assisted resolution from a price-label image (PaddleOCR extra).
Hermes skill package with install/config/cron guidance.
Standard open-source project files: CI, issue templates, PR template, contributing guide, security policy, code of conduct.
Related MCP server: Taiwan Price Compare MCP
Tool | Purpose |
| Add a product URL with optional target price, sale notifications, sizes, and display name. |
| List tracked products. |
| Check one product and record price history/events when possible. |
| Check all active products; useful for cron jobs. |
| Read historical prices for a product. |
| Deactivate tracking for a product. |
| Search adapters for candidate products from a name, OCR text, or product code. |
| Run optional OCR on a local image, then resolve product candidates from the extracted text. |
git clone https://github.com/bolin8017/retail-price-tracker-mcp.git
cd retail-price-tracker-mcp
uv sync --extra dev # locked versions, same toolchain as CI
uv run pytest
uv run ruff check .Run the MCP server over stdio:
PRICE_TRACKER_DB="$PWD/tracker.db" uv run retail-price-tracker-mcpUse the small CLI helper for smoke tests:
uv run retail-price-tracker add 'https://www.uniqlo.com/tw/zh_TW/products/E123456-000' --name 'Demo shirt' --target-price 390
uv run retail-price-tracker list
uv run retail-price-tracker resolve 'AIRism 棉質寬版圓領T恤' --limit 3OCR is shipped as an optional extra so the core install stays lightweight and no models are downloaded by default. Install it only when you need to resolve a product from a photo of a price label:
uv pip install -e '.[ocr]' # pulls in PaddleOCR
uv run retail-price-tracker resolve-image /path/to/label.jpg --limit 5The image is run through OCR locally, price/size-only lines are stripped, and the
remaining text becomes a query for resolve_product. The project does not build a
custom OCR model; PaddleOCR is the primary engine. Without the extra, the tool
raises a clear error explaining how to install it.
Add this to ~/.hermes/config.yaml. The package is not published to PyPI yet, so
uvx installs and runs it straight from GitHub:
mcp_servers:
retail_price_tracker:
command: "uvx"
args: ["--from", "git+https://github.com/bolin8017/retail-price-tracker-mcp", "retail-price-tracker-mcp"]
env:
PRICE_TRACKER_DB: "/home/USER/Documents/Hermes/price-tracker/tracker.db"
timeout: 120
connect_timeout: 60Running from a local clone (development / offline): if you already have the
repo checked out, point Hermes at it so edits take effect immediately and no
network fetch is needed — replace the command/args above with:
command: "uv"
args: ["run", "--directory", "/path/to/retail-price-tracker-mcp", "retail-price-tracker-mcp"]After restarting Hermes, tools will be available with names like:
mcp_retail_price_tracker_add_product
mcp_retail_price_tracker_check_all
mcp_retail_price_tracker_price_history
mcp_retail_price_tracker_resolve_productSee docs/hermes.md and skills/retail-price-tracker/SKILL.md for a full Hermes workflow.
Use the retail price tracker MCP tools to run check_all. If there are price drops, below-target events, sale labels, restocks, or errors needing attention, summarize them for the user in concise Traditional Chinese. If nothing changed, stay silent.MCP first: the core should work outside Hermes.
Hermes friendly: ship a skill and cron templates for a polished Hermes experience.
No fake prices: adapters must return explicit unsupported/unknown results instead of made-up data.
Local by default: SQLite on the user's machine; no hosted service required.
Adapter-based: stores are plugins around a stable tracking core.
Harden UNIQLO Taiwan live price fetching with more URL formats and stock detail support.
Size/color stock tracking.
Improve OCR resolution accuracy and add an EasyOCR fallback provider.
changedetection.io backend integration.
More adapters: GU, MUJI, momo, booksellers.
HTTP MCP transport and Docker image.
Tracked URLs, prices, and shopping preferences are stored locally in SQLite by default. See docs/security.md.
Please read CONTRIBUTING.md. Bug reports and adapter contributions are welcome.
MIT. See LICENSE.
Add a retail product URL to the tracker.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| target_price | No | ||
| notify_on_sale | No | ||
| sizes | No | ||
| name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as duplicate handling, authentication requirements, or side effects like triggering initial price checks. For a creation tool, this is a critical omission.
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, making it concise but at the expense of necessary detail. It is front-loaded with the main action but lacks structure for completeness.
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 5 parameters, no annotations, and an output schema, the description is incomplete. It does not explain the purpose of each parameter, the return value, or post-add behavior. The agent would need to infer too much from parameter names alone.
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 explain any parameters. While some parameter names are self-explanatory (e.g., url, notify_on_sale), the description adds no value beyond the schema, leaving agents without guidance on format or usage constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (add) and object (retail product URL) and destination (tracker), distinguishing it from siblings like remove_product or check_product. However, it does not specify the tracker's purpose (price tracking) or clarify that the tool adds a new product to monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like check_product or list_products. The usage context is implied (adding new products), but there is no explicit when-not or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check all active products; useful for scheduled jobs.
| 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?
No annotations are provided, so the description carries full burden. It only says 'check' without disclosing whether it is read-only, what side effects occur, or what happens on failure. Lacks detail on behavioral traits.
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 very concise with one sentence, no wasted words. However, could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema, the description is short but misses behavioral context. It names the resource and use case but doesn't explain what 'check' entails, which is a gap.
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; description adds meaning by specifying 'active products', clarifying the scope 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 verb 'check' and the resource 'all active products', distinguishing it from sibling tools like check_product (individual) and list_products (listing).
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 'useful for scheduled jobs', implying a batch use case, but does not explicitly contrast with alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one product and record history/events.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey effects. 'Record history/events' implies mutation (writing history), but doesn't clarify whether this is a side effect or what exactly is recorded. No mention of permissions, rate limits, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it is arguably under-specified for a tool with an output schema and side effects. Concise but not sufficiently informative.
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?
With one parameter and an output schema, the description should provide context on what 'check' entails and what the output looks like. It mentions 'record history/events' but leaves ambiguity about the return value and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one required parameter 'product_id' with no description (0% coverage). Description does not explain what product_id represents or how to obtain it, adding no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Check one product' indicating a single-product operation, and 'record history/events' suggests additional logging. It distinguishes from sibling 'check_all' (checks multiple) but 'check' is vague compared to more specific verbs like 'resolve' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_products' or 'price_history'. The description implies use for a single product with history recording, but doesn't exclude other scenarios or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tracked products.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | 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. It only states 'List tracked products' without disclosing read-only nature, auth requirements, rate limits, or any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. No redundant information, but it is perhaps too brief at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to provide enough context to use the tool effectively. It does not differentiate from sibling tools like check_all, and it omits behavior regarding the active_only parameter. Incomplete for a tool with one parameter.
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 only parameter 'active_only' has 0% schema description coverage. The tool description does not explain its meaning or effect, though the name implies filtering active products. The agent receives no additional semantic help.
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 'List tracked products' clearly states the verb and resource, distinguishing it from sibling tools that perform actions like add, check, remove, or resolve. However, it lacks specific scope (e.g., all products or only active ones by default).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like check_all or price_history. The description does not mention appropriate contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return price history for a product.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | ||
| days | 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 but only states a bare purpose; does not disclose read-only nature, limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but too sparse; front-loads the main point but omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description lacks sufficient context for a tool with 2 parameters; missing behavior details like date range handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter descriptions and the description does not explain product_id or days; no added value beyond the schema's names and 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?
The description clearly states the tool returns price history for a product, which distinguishes it from sibling tools like add_product or list_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivate tracking for a product.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Deactivate tracking,' which implies a state change but provides no details on permanence, reversibility, side effects, or required permissions. Without annotations, this is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it under-specifies the tool's behavior and context. It earns its place but could be more informative while remaining 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?
Given the tool has an output schema but no annotations, the description should cover return behavior, error conditions, or side effects. It does not, leaving the agent with minimal understanding of what happens after invocation.
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 tool name and description are expected to clarify the parameter. The description only implies 'product_id' identifies the product to deactivate, but adds no constraints or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deactivate tracking') and the target resource ('a product'), making it distinct from sibling tools like 'add_product' or 'check_product' which have different verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to deactivate vs. add or check a product). The description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search store adapters for product candidates matching a query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states 'Search store adapters' without disclosing side effects, authentication needs, rate limits, or read-only nature. Schema parameters give no additional behavioral 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?
A single, front-loaded sentence efficiently conveys the primary action. While very brief, it is not wasteful; however, it sacrifices necessary 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?
Given the tool has an output schema but no annotations, the description is insufficient. It lacks details about output format, error handling, pagination, or ordering of results, which an agent would need for proper invocation.
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%, yet the description only adds minimal context: 'matching a query' clarifies the query parameter, but limit is unexplained. Neither parameter's format, constraints, or behavior is described.
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 ('store adapters for product candidates'), making the core action clear. It is distinct from siblings like 'add_product' or 'check_product', which involve different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives such as 'list_products' or 'check_product'. There are no when-to-use or when-not-to-use examples.
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.1.0add_productcheck_allcheck_productlist_productsprice_historyremove_productresolve_productEach tool has a clear and distinct purpose: adding, checking (individual or all), listing, viewing history, removing, and searching products. No overlap.
All tool names follow a consistent verb_noun pattern with underscores (e.g., add_product, check_all). The pattern is uniform and predictable.
Seven tools provide a well-scoped set for retail price tracking, covering core operations without excess or deficiency.
The set covers add, remove, list, check, history, and search. Missing an update operation for product details, but core tracking workflow is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Track prices & price history on any online shop, with alerts and an API
Track price drops, stock-outs, restocks, and new/removed products across Shopify stores.
AU price comparison via MCP — search, compare, track. 6 tools; anonymous demo (30/day/IP).
MCP server for ua_e_commerce_price_tracker_mcp
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bolin8017/retail-price-tracker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server