Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Track prices & price history on any online shop, with alerts and an API
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Works in Claude on the web, desktop and mobile:
https://mcp.pricewatcha.comRun this in your terminal
claude mcp add --transport http pricewatcha https://mcp.pricewatcha.comPaste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"pricewatcha": {
"url": "https://mcp.pricewatcha.com"
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"pricewatcha": {
"type": "http",
"url": "https://mcp.pricewatcha.com"
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
ChatGPT connects only to servers on the internet:
https://mcp.pricewatcha.comMenu names can differ slightly by plan and over time.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
We have not read this server’s tool list yet; we check endpoints in rotation.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
The registry name was verified with the GitHub account pricewatcha, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
Not checked yet; we check endpoints in rotation
Not checked yet; we check endpoints in rotation
Not checked yet; we read the tool list when we check the endpoint
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs in the maker’s cloud. Connect over the internet with nothing to install, but what you send passes through the maker’s servers.
The GitHub repo last changed –, and the latest version (0.1.7) reached the registry 2 months ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. It connects by URL, so apps that accept remote MCP servers work too, such as ChatGPT in developer mode.
In the same category: Spec Driven Development, Remote Desktop Commander, AI Deprecations
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
AI model shutdown dates, replacements, change feed and webhook alerts for 8 providers.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
The Pricewatcha API is the Structured Product Price Intelligence Platform for developers, automation and AI Agents.
The Pricewatcha API derives from the pricewatcha.com application. It provides price tracking, alerts and product intelligence beyond the Pricewatcha dashboard. This repository documents the public HTTP API, OpenAPI schema, official SDKs, MCP server and examples. It does not contain the production web application or scrapers.
Status: Available · Version: v1 · Base URL: https://pricewatcha.com/api/v1
Interactive API keys (browser): Profile & API Keys
Optional: verify connectivity with GET https://pricewatcha.com/api/v1/health. Then pick one of the three paths below.
Use demo product IDs from the demo catalog or search the catalog:
curl -s "https://pricewatcha.com/api/v1/products/demo_iphone_15_pro"
curl -s "https://pricewatcha.com/api/v1/search?q=iphone+15&limit=10"
Search is case-insensitive token AND (all terms must appear; word order does not matter). Results include the full Pricewatcha catalog, not only URLs submitted via POST /track. Use product_id from search for product and price-history endpoints (prod_* or demo_*).
curl -s -X POST "https://pricewatcha.com/api/v1/track" \
-H "Content-Type: application/json" \ -d '{"url": "https://www.backmarket.de/de-de/p/example-product"}'
curl -s "https://pricewatcha.com/api/v1/products/{productId}/price-history"
POST /track returns HTTP 200 with a bounded server-side long-poll (~25s). Use product_id from the response for price history. Optional: send Authorization: Bearer pwk_live_… for higher track, search and product-read quotas.
Fast shops return status: "completed" with the full product in one call. Slow shops return status: "running" with a job_id. Poll GET https://pricewatcha.com/api/v1/jobs/{jobId} until the job is completed or failed. More detail: Async track & poll.
Create a key in Profile & API Keys, then:
curl -s -X POST "https://pricewatcha.com/api/v1/alerts" \
-H "Authorization: Bearer pwk_live_YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{ "product_id": "prod_a1b2c3d4e5", "notify_on_drop": true, "min_threshold_price": 500.00, "webhook_url": "https://your-n8n-instance.com/webhook/abc", "notify_email": true }'
For authentication and data boundaries, see Authentication and Data boundaries.
No credential required for catalog search, product detail, price history and async track/poll. Without a key those endpoints use anonymous rate limits. Send an API key to use the higher per-account track, search and product-read quotas.
Protected API v1 endpoints (alerts, webhooks, authenticated track callbacks) use:
Authorization: Bearer pwk_live_…
| Credential | Format | When to use |
|---|---|---|
| API key | pwk_live_… | Recommended for scripts, agents, n8n and server integrations. Create in Profile & API Keys. |
| Login session token | JWT from POST https://pricewatcha.com/api/auth/login | Website UI and headless key bootstrap only |
Do not use the login session token for alerts, webhooks or other API v1 calls once you have an API key.
See Access model for which routes are public vs authenticated.
Log in and open Profile & API Keys to create and manage API keys in your browser. The full secret is shown once at creation.
For agents without a browser, use headless key bootstrap below.
Using your key on protected endpoints:
curl -s -X POST "https://pricewatcha.com/api/v1/alerts" \
-H "Authorization: Bearer pwk_live_YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{"product_id": "prod_a1b2c3d4e5", "notify_on_drop": true}'
If an agent must obtain API credentials without a browser, authenticate once with the same email and password as on the website, create an API key, then use pwk_live_… for all further calls. This is not a separate agent login: it is the normal Pricewatcha account login exposed as an HTTP endpoint.
POST https://pricewatcha.com/api/auth/login accepts JSON email and password and returns a short-lived access_token (login session token). The Developer page login modal calls the same endpoint; in a script or agent you call it directly with curl or your HTTP client.
POST https://pricewatcha.com/api/auth/register).access_token only to create keys; for alerts and webhooks use the pwk_live_… key from step 2.Step 1: Login
curl -s -X POST "https://pricewatcha.com/api/auth/login" \
-H "Content-Type: application/json" \ -d '{"email": "you@example.com", "password": "YOUR_PASSWORD"}'
Response (HTTP 200), AuthResponse:
access_token (string): login session token (JWT)token_type (string): always "bearer"user (object): id (string, UUID), email (string), email_verified (boolean){
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "token_type": "bearer", "user": { "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "email": "you@example.com", "email_verified": true } }
Send the token as Authorization: Bearer in step 2. Session tokens expire; do not store them as the long-term credential for an agent.
Step 2: Create API key
curl -s -X POST "https://pricewatcha.com/api/keys" \
-H "Authorization: Bearer ACCESS_TOKEN_FROM_STEP_1" \ -H "Content-Type: application/json" \ -d '{"name": "agent bootstrap"}'
Response (HTTP 200), CreateApiKeyResponse:
id (integer): key IDname (string): label from the requestkey_prefix (string): first 12 characters of the key (for display)key (string): full secret; returned only on create, not on listis_active (boolean)created_at (string, ISO 8601 datetime)last_used_at (string or null)revoked_at (string or null){
"id": 42, "name": "agent bootstrap", "key_prefix": "pwk_live_ab", "key": "pwk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "is_active": true, "created_at": "2026-05-27T14:30:00.123456", "last_used_at": null, "revoked_at": null }
Store key securely. Use it on alerts, webhooks and other protected API v1 endpoints, not the session token from step 1.
| Method | Path | Auth | Description |
|---|---|---|---|
GET | /api/v1/health | - | Health check |
GET | /api/v1 | - | Discovery and disclaimer |
POST | /api/v1/track | - | URL ingestion (long-poll) |
GET | /api/v1/jobs/{jobId} | - | Job status |
GET | /api/v1/products/{productId} | - | Product intelligence |
GET | /api/v1/products/{productId}/price-history | - | History and trend |
GET | /api/v1/search?q= | - | Keyword search (limit max 200) |
GET | /api/v1/openapi.json | - | Live OpenAPI 3.1 |
POST | /api/auth/login | - | Login (short-lived session token) |
POST | /api/keys | Session token | Create API key |
GET / DELETE | /api/keys … | Session token or key | List / revoke keys |
* | /api/v1/alerts … | API key | Price alerts |
* | /api/v1/watchlist / …/watch | API key | Continuous price watchlist |
* | /api/v1/webhooks … | API key | Webhook subscriptions |
Machine-readable contract: openapi/openapi.yaml · Live: GET https://pricewatcha.com/api/v1/openapi.json
The following limits apply and may change without notice.
| Class | Endpoint | Anonymous | Authenticated (API key) |
|---|---|---|---|
| Track (concurrent) | POST /track | ~2 in-flight jobs | ~4 in-flight jobs |
| Track (burst) | POST /track | ~10 jobs / 60s | ~20 jobs / 60s |
| Track (hourly) | POST /track | ~40 jobs / hour | ~120 jobs / hour |
| Track (daily) | POST /track | ~80 jobs / day | ~400 jobs / day |
| Job poll | GET /jobs/{id} | ~40 req/min per client | same |
| Search (burst) | GET /search | ~20 req / 60s | ~40 req / 60s |
| Search (hourly) | GET /search | ~60 req / hour | ~180 req / hour |
| Search (daily) | GET /search | ~200 req / day | ~1000 req / day |
| Read (burst) | /products, /price-history | ~60–120 req/min per client | ~240 req / 60s |
| Read (hourly) | /products, /price-history | ~180 req / hour | ~540 req / hour |
| Read (daily) | /products, /price-history | ~600 req / day | ~3000 req / day |
| Health | /health and / | Unlimited | Unlimited |
Send Authorization: Bearer pwk_live_… on POST /track, GET /search, or product reads to use the authenticated tier. Those endpoints remain available without a key at the anonymous limits.
Client identity: anonymous limits are keyed by client IP. Behind Cloudflare the API prefers
CF-Connecting-IPoverX-Forwarded-Forso edge proxy IPs are not treated as distinct clients. The hosted MCP server forwards a stableX-Pricewatcha-Client-Id(OAuth token hash, else connecting-IP hash) with a shared proxy secret so MCP callers are not all bucketed under one egress IP. Authenticated track, search and product-read quotas are keyed by account (owner_id), not IP.
Monitor
X-RateLimit-Remainingand honor429with exponential backoff.X-RateLimit-Policynames which window the headers refer to (track,track_hourly,track_daily,track_concurrent,job_read,search,search_hourly,search_daily,read,read_hourly, orread_daily).
Track quotas are counted from persisted jobs (api_track_jobs by client key or account), so they apply across multiple app instances. A long-poll that holds the HTTP connection for ~25s still counts as one track job when created — sequential tracks spaced farther apart than 60s will not trip the burst window, but hourly/daily and concurrent caps still apply.
Agents should prefer: start track → poll GET /jobs/{id} with backoff (not every 1–2s) → read product/history once complete. Retrying POST /track with the same URL while that job is still queued/processing reuses the existing job and does not consume another concurrent slot. Jobs left queued/processing longer than the scrape timeout (default 600s) are failed so slots cannot leak across deploys.
Search and product-read quotas are in-memory per app instance (not shared across Railway replicas the way track jobs are). Authenticated callers still get the higher per-account windows. Polling the same catalog queries on a short interval will still trip the hourly/daily search windows.
Exact numbers may change without notice (env overrides: API_V1_TRACK_*, API_V1_TRACK_AUTH_*, API_V1_JOB_READ_*, API_V1_READ_*, API_V1_READ_AUTH_*, API_V1_SEARCH_*, API_V1_SEARCH_AUTH_*).
When rate limiting is active, responses may include:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests in the window |
Only the beginning is shown; read the rest in the repo