Skip to main content
Glama

Create price alert

create_price_alert

Create a price alert for a product. Use notify_on_drop / notify_on_rise for any price change without a numeric threshold, and/or min_threshold_price / max_threshold_price for target prices. At least one of those four settings is required. Requires a Pricewatcha API key (pwk_live_...) from https://pricewatcha.com/en/developers#api-keys. 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
NameRequiredDescriptionDefault
nameNoOptional alert name
api_keyYesPricewatcha API key (pwk_live_...)
product_idYesPublic product ID (prod_... or demo_...)
webhook_urlNoOptional HTTPS webhook URL
notify_emailNoSend email notifications (default true)
notify_on_dropNoNotify on any price drop. No threshold required.
notify_on_riseNoNotify on any price increase. No threshold required.
max_threshold_priceNoNotify when the price rises to or above this value.
min_threshold_priceNoNotify when the price drops to or below this value.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
alert_idYes
currencyYes
is_activeYes
created_atYes
product_idYes
updated_atYes
webhook_urlNo
notify_emailYes
notify_on_dropYes
notify_on_riseYes
last_triggered_atNo
max_threshold_priceNo
min_threshold_priceNo

TDQS

A4.4/5.0
Behavior4/5

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

With only 'false' annotation flags, the description carries the behavioral burden, and it does so by specifying the API key format, location, and the structured error contract. It doesn't describe post-creation side effects or whether the alert starts immediately, but this is a modest gap.

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?

The action is front-loaded in the first sentence, followed by focused sentences on parameter choice, requirement, auth prerequisite, and error output. Each clause carries semantic weight, though the paragraph is slightly longer than strictly necessary.

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

Completeness5/5

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

Since the tool has an output schema, the definition doesn't need to describe successful return values. The description covers authentication, the mandatory conditional fields, API key source, and error structure, giving an agent all crucial non-obvious context for a successful call.

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 schema already covers 100% of parameter details, giving a baseline of 3. The description adds value beyond the schema by grouping the threshold-free flags separately from the numeric threshold settings and by introducing the cross-field requirement that at least one is mandatory.

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

Purpose5/5

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

The verb 'Create' combined with 'price alert' and 'for a product' states exactly what the tool does. The subtle distinction with siblings like update_price_alert is immediately obvious from the verb choice.

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?

It explicitly explains the two operating modes: threshold-free notify_on_drop/notify_on_rise vs numeric min/max_threshold_price, and states the crucial 'at least one of those four settings is required' constraint. It provides clear create-context, though it doesn't explicitly name update_price_alert as the alternative for modifying existing alerts.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool clearly maps to a distinct resource and action: price alert CRUD verbs (create/get/list/update/delete) are unambiguous, and get_api_status vs get_job_status are separated by scope (service health vs async job polling). track_product, search_products, get_product, and get_price_history each address a different part of the product workflow with no meaningful overlap.

Naming Consistency5/5

All 11 tools follow a consistent verb_noun snake_case pattern: create_price_alert, get_price_history, track_product, list_price_alerts, and so on. Verbs are precise and nouns are stable across the set, making the API surface predictable.

Tool Count5/5

At 11 tools, the server is well-scoped for its purpose: alert management, product search, price history, tracking, and status checks each earn their place. No tool feels redundant or excessive for a price-intelligence domain.

Completeness4/5

The price alert lifecycle is fully covered with create/get/list/update/delete, and product search/tracking/history are solid. A minor gap is the lack of a way to list or stop all tracked products/jobs besides polling a known job_id, but this can be worked around and core workflows are complete.