pricewatcha

Track product

track_product

Submit a public product URL for price tracking. Waits up to ~25s server-side; fast shops return status "completed" with product in one call. Slow jobs return status "running" with job_id — poll get_job_status. On failure, returns a structured error object with fields error.code, error.message, error.http_status, error.retry_recommended, and error.retry_after_seconds.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Public product page URL from a supported shop
`watch`	No	If true (API key required), enroll the product for continuous scheduler updates.
`api_key`	No	Optional API key (pwk_live_...). Required for watch/refresh.
`refresh`	No	If true (API key required), force a re-scrape even if the URL is already in the catalog.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`hint`	No
`error`	No
`job_id`	Yes
`status`	Yes
`product`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 7, 2026

addedInput schema / properties / api_key

Added value: +{
+  "description": "Optional API key (pwk_live_...). Required for watch/refresh.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / refresh

Added value: +{
+  "description": "If true (API key required), force a re-scrape even if the URL is already in the catalog.",
+  "type": "boolean"
+}

addedInput schema / properties / watch

Added value: +{
+  "description": "If true (API key required), enroll the product for continuous scheduler updates.",
+  "type": "boolean"
+}

First observedJun 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Adds real context beyond annotations: the ~25s server-side wait, the completed/running status dichotomy, and the structured error object with retry_recommended and retry_after_seconds. Annotations cover the safety profile (non-destructive, open-world), so this extra latency and failure-mode disclosure is genuinely additive.

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

Conciseness5/5

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

Three tight sentences, front-loaded with the primary action, then the sync/async branching, then error shape. No wasted prose.

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, yet the description still usefully sketches the error object and the polling handoff. The main gap is that it never mentions the API-key requirement for watch/refresh in prose, leaving that solely to the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so url/watch/refresh/api_key are already documented in the schema. The description adds no parameter-level detail (e.g., what 'supported shop' means), so baseline 3 is appropriate.

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 ('Submit a public product URL for price tracking') with the async outcome described. The action is clear and distinct from read-only siblings like get_product, though it doesn't explicitly differentiate itself from watch_product, which overlaps with the `watch` parameter here.

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

Usage Guidelines4/5

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

Explains the two possible outcomes and routes the agent to the correct alternative, poll get_job_status, when status is 'running'. It gives clear operational context but no explicit when-not-to-use guidance or contrast with watch_product.

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

All pricewatcha tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.