Skip to main content
Glama
Abomination81

Amazon Public Fetch MCP

by Abomination81
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Amazon Public Fetch MCP

Give Grok Bot a route through your own PC. Read public Amazon product pages using your computer's internet connection or an HTTP(S) proxy you configure locally.

Built by Abomination81 · Project page · Download source · MIT

Grok Bot / local MCP client
           │ your existing computer connection
           ▼
      Your Mac or PC
      Amazon Public Fetch
           │ local internet or your configured proxy
           ▼
   Public Amazon /dp/ page
           │
           └── title · ASIN · visible price · feature bullets

This is a local stdio MCP server, not a hosted proxy. Install it on the computer whose network you want to use. Publishing this repo does not route a cloud bot through your PC: the bot must already have a working computer connection that can launch local commands, or a local MCP client must launch this server. Client setup varies; this project does not provide a Grok Bot account, connection service, or remote MCP endpoint.

Install

Requires Python 3.11+. Download and unzip the source, or clone it:

git clone https://github.com/Abomination81/amazon-public-fetch-mcp.git
cd amazon-public-fetch-mcp

macOS / Linux

python3 -m venv .venv
.venv/bin/python -m pip install .
.venv/bin/python -c "from mcp_server import health; print(health())"

Windows PowerShell

py -3 -m venv .venv
.\.venv\Scripts\python.exe -m pip install .
.\.venv\Scripts\python.exe -c "from mcp_server import health; print(health())"

The health command checks local engine availability and proxy configuration. It does not test access to Amazon. There are no API keys to obtain.

Related MCP server: Amazon MCP Server

Connect Grok Bot or another client

With your existing Grok Bot computer connection, tell it:

Run Amazon lookups on my connected computer using the Python executable in this project's .venv. Start python -m mcp_server as a local stdio MCP server if supported. Use amazon_product for public Amazon product URLs or ASINs. If the connection only supports shell commands, call the Python library on that same computer. Report blocked or missing results honestly.

For clients that accept an mcpServers JSON configuration, replace the executable with your absolute local path:

{
  "mcpServers": {
    "amazon-public-fetch": {
      "command": "/absolute/path/amazon-public-fetch-mcp/.venv/bin/python",
      "args": ["-m", "mcp_server"]
    }
  }
}

Windows command example: C:\\path\\amazon-public-fetch-mcp\\.venv\\Scripts\\python.exe. Client configuration formats differ; the executable and -m mcp_server arguments are the important parts. No working-directory setting is needed after installation.

A direct library call on macOS/Linux (use the Windows Python path above on Windows):

.venv/bin/python -c "import json; from mcp_server import amazon_product; print(json.dumps(amazon_product('ASIN_OR_PRODUCT_URL'), ensure_ascii=False, indent=2))"

Replace ASIN_OR_PRODUCT_URL with an actual 10-character ASIN or full product URL. The placeholder intentionally returns invalid_product_url if used unchanged.

Your network or your proxy

Without proxy environment variables, requests use the computer's normal network route. A device-wide VPN can affect that route. System/browser proxy settings and PAC files are not automatically detected.

The first nonempty variable wins: AMAZON_FETCH_PROXY, then HTTPS_PROXY, then HTTP_PROXY. Only HTTP and HTTPS proxy URLs are supported consistently across the engines. ALL_PROXY, lowercase variants and NO_PROXY bypass rules are not used. A configured proxy failure does not intentionally fall back to a direct connection.

Example for a proxy already running on your own computer:

# macOS / Linux: launch the server through your existing local proxy
AMAZON_FETCH_PROXY=http://127.0.0.1:8080 .venv/bin/python -m mcp_server
# Windows PowerShell
$env:AMAZON_FETCH_PROXY = "http://127.0.0.1:8080"
.\.venv\Scripts\python.exe -m mcp_server

You can also put AMAZON_FETCH_PROXY in the MCP client's env configuration. The port above is only an example; this package does not start a proxy. .env files are not auto-loaded. If your proxy requires credentials, enter them through your local client's secure configuration; never paste them into issues or chat. Proxy addresses, usernames and passwords are omitted from health/tool results.

Tools

Tool

Returns

health

Installed engine modules, proxy configuration validity and request limits

amazon_fetch(url, include_html=False, max_engine=None)

Success, HTTP status, engine, block detection, canonical URL, ASIN, titles and byte count

amazon_product(url, max_engine=None)

The fetch result plus title, visible price text and up to eight feature bullets

Accepted marketplaces: amazon.com, amazon.co.uk, amazon.ca, amazon.de, amazon.co.jp. An ASIN alone defaults to amazon.com. Full URLs must use HTTPS and a /dp/ASIN product path. Product slugs, referral suffixes, query parameters and fragments are removed. Short links, search, account, login, order and Vine pages are rejected.

Fetch order: httpx → curl_cffi → rnet → Playwright. Base installation includes the first two. max_engine caps the ladder at the named engine; it does not select only that engine. Missing optional modules are skipped. Install the optional engines if needed:

.venv/bin/python -m pip install '.[extra]'
.venv/bin/python -m playwright install chromium

On Windows, use .\.venv\Scripts\python.exe for both commands. Playwright uses a fresh headless browser with JavaScript, service workers and subresources disabled; it never opens your browser profile. It is a static HTML fallback, not a logged-in or interactive browsing session.

Limits and privacy

  • Amazon can return a block, CAPTCHA, regional variation, unavailable price, or incomplete HTML on any network. A residential connection does not guarantee access.

  • A successful result requires an HTTP 200 response with a product title. Prices are page text, not a checkout quote. The fallback price parser does not invent a currency.

  • HTTP engines allow at most three validated redirects and stream at most 5 MiB of decoded HTML. Requests use 20-second timeouts. Browser navigation has the same timeout; its 5 MiB HTML check occurs after the browser loads the document. A complete multi-engine call may take longer than 20 seconds.

  • HTTP 429 and responses with a supported 503 Retry-After stop the ladder. Wait before trying again; there is no background retry queue.

  • No API keys, telemetry, developer callback, cookie import, saved browser profile, local result files, or listening HTTP server. The source contains only the public Abomination81 identity.

  • Amazon sees the connection IP and requested product. A configured proxy can see connection metadata. Your MCP client receives results and may retain them. This is not an anonymity tool.

  • Raw HTML is opt-in, can be large, and is untrusted page content. Treat page text as data rather than instructions.

More detail: SECURITY.md.

Development

python -m pip install -e . pytest build
python -m pytest -q
python -m build

Tests cover URL boundaries, tracking removal, redirects, safe errors, response limits, extraction, rate limits and local proxy routing. CI runs the base package on Linux, Windows and macOS. Optional rnet checks run when installed; browser behavior needs Chromium and a separate smoke check.

Independent project. Not affiliated with Amazon or xAI. Use public data responsibly and follow the services' terms.

Available Tools

3 tools
amazon_fetchA

Fetch a public Amazon URL (or a 10-char ASIN) through a local fetch ladder: httpx → curl_cffi → rnet → playwright. Uses fresh sessions. Stops on rate limits.

Returns status, engine used, ASIN, titles, and size. Set include_html=true only when you need the raw page (large). max_engine caps the ladder (httpx|curl_cffi|rnet|playwright).

NameRequiredDescriptionDefault
urlYes
max_engineNo
include_htmlNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does much of it: it names the four-stage fallback ladder, states fresh sessions are used, that it halts on rate limits, and that raw HTML is large. It doesn't say what happens when all engines fail or whether any local environment (browsers for playwright) is required, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and mechanism in the first clause, then parameters, then the return shape. Compact and mostly waste-free, though the line-broken layout scatters related details and the return-value sentence is partly redundant with the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a scrape-and-fallback tool this covers the mechanics an agent needs: the engine ladder, the rate-limit stop, and the size warning on raw HTML. An output schema exists so return values needn't be detailed, though the description mentions them anyway; missing failure-mode behavior is the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it explains all three: url accepts a public Amazon URL or 10-char ASIN, include_html controls raw-page inclusion and warns of size, and max_engine caps the ladder with the four engine names. Minor gap: max_engine's effect (cap = start-at vs stop-at) is ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (fetch a public Amazon URL or 10-char ASIN) plus the mechanism (local fetch ladder). It doesn't mention the amazon_product sibling, so an agent must infer that this is the raw-page path and that one is the structured-data path. Still, the scope ('public Amazon URL', 'through a local fetch ladder') is concrete enough to pick it out of a three-tool set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives one explicit conditional — 'Set include_html=true only when you need the raw page (large)' — and a stopping condition ('Stops on rate limits'), which is real guidance. However, it never says when to prefer this over amazon_product, and the exclusions are limited to a single parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amazon_productB

Fetch a public Amazon product page and return a small summary: ASIN, title, visible price text, and feature bullets. Same ladder as amazon_fetch.

NameRequiredDescriptionDefault
urlYes
max_engineNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It discloses that the page is public and that it fetches a summary, and hints at an engine fallback ladder via the sibling reference, but says nothing about anti-bot handling, timeouts, missing price/feature data, or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with the outcome and returned fields front-loaded. The final sentence is terse and dependent on sibling context, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be fully explained, and the description summarizes them anyway. However, with no annotations and 0% parameter coverage, leaving URL format and engine behavior underspecified makes the definition only minimally sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only implies that 'url' is a product page URL. The 'max_engine' parameter and its enum values are never explained in this tool's description; 'Same ladder as amazon_fetch' forces the agent to consult another tool to understand it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Fetch') and resource ('public Amazon product page') and lists the exact summary fields returned (ASIN, title, price text, feature bullets). It implicitly differentiates from the sibling amazon_fetch by being product-specific and summary-oriented, though it never explicitly says how the two differ.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is 'Same ladder as amazon_fetch,' which does not explain when to choose this tool over amazon_fetch or health. There is no explicit when-to-use, when-not-to-use, or prerequisite information; the agent must infer that this is for product pages.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

healthB

What this connector can do right now: which fetch engines are installed, and the honest limits (public pages only; must run on a home/residential machine).

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does add genuinely useful behavioral context beyond the name: fetches are limited to public pages and require a home/residential machine. It does not say whether the call is read-only/side-effect free or what a degraded/non-ready response implies, so the disclosure is partial rather than complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler, and the two substantive items (engine inventory, limits) come first. The framing clause 'What this connector can do right now' is slightly indirect where a direct verb would be tighter, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description supplies the one thing structured fields cannot: the environmental constraints (public pages, residential host). For a zero-parameter diagnostic tool this is close to sufficient, missing only a cue on when to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify about arguments. The description correctly focuses on what the call surfaces instead of inventing parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description says the tool reports which fetch engines are installed plus the connector's limits, which is a recognizable resource, but it is phrased as a capability statement ('What this connector can do right now') rather than an explicit verb+resource like 'Report connector health and installed fetch engines'. It implicitly distinguishes itself from the fetch siblings by being about the connector itself rather than fetching, but never names them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use statement, no mention of the amazon_fetch / amazon_product siblings, and no precondition such as 'call this before fetching to confirm an engine is available'. The agent must infer that this is a diagnostic/probe tool from the content alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedamazon_fetch
    • First observedamazon_product
    • First observedhealth
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation4/5

health is clearly a diagnostic tool separate from fetching. amazon_fetch and amazon_product overlap because both can fetch Amazon product pages, but the descriptions clarify that amazon_product returns a focused product summary while amazon_fetch is the generic fetch ladder with optional raw HTML.

Naming Consistency3/5

The names use mixed conventions: health is a bare noun, amazon_fetch follows a prefix_verb pattern, and amazon_product follows a prefix_noun pattern. They are still readable and grouped by the amazon_ prefix, but the verb/noun inconsistency prevents a higher score.

Tool Count5/5

Three tools are well-scoped for a narrow public-Amazon fetch connector: one diagnostic, one generic fetcher, and one product-specific summarizer. Each tool has a clear role and there is no obvious bloat.

Completeness4/5

The surface covers health checking, generic URL/ASIN fetching, and product-page summarization, which are the core operations for this domain. A minor gap is that non-product Amazon pages only get the generic fetch output rather than richer summaries, but include_html and the generic fetcher provide a workaround.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers