Give every price alert an expiry date and clear stale ones weekly

How it works

1. Copy your alert list from the TradingView Alerts panel into a CSV or text file. Optionally, if you already run a local read-only MCP that can list alerts, paste that output instead. Columns: symbol, alert name or id, level, created date, note, expiry, and latest_price that you copied from the platform. Leave blanks blank; do not guess.
2. Flag alerts with no note, no expiry, same-symbol duplicates at the same level, alerts older than {{max_age_days}} days, or levels more than {{max_distance_pct}} from the latest_price column you supplied (mark quote-missing if that cell is blank; never a model estimate).
3. Propose an expiry date for each alert that lacks one, based on your own rule (for example {{expiry_trading_days}} trading days). Do not propose delete when the note contains a keep-until date. Missing expiry → propose an expiry only. Missing note → flag for you to write the note, never delete.
4. Show the clean-up list and wait for confirmation.
5. Apply the confirmed changes yourself in the TradingView UI; the agent only logs what was proposed with a before/after diff.

Copy-paste prompt

You audit my personal TradingView alerts. These are reminders for my own review, not trade instructions.
1. Read only the alert table I paste (symbol, alert name or id, level, created date, note, expiry, latest_price). Do not invent rows, ids, prices, or expiries. If latest_price is blank, mark quote-missing and do not estimate.
2. Flag using my verbatim rules only: missing note, missing expiry, same-symbol duplicates at the same exact level, age over {{max_age_days}} days, and distance over {{max_distance_pct}} versus the latest_price column. Exempt any alert whose note contains a keep-until date. Do not add flags based on whether a level looks important.
3. Actions: missing expiry → propose expiry only, using {{expiry_trading_days}} trading days from the created date; if created date is missing, flag it and do not invent a date; missing note → flag "add note", never delete; age or distance breach → propose delete only when not exempt; duplicates → flag both and do not pick a winner unless one row has a note and the other does not. Cap at {{max_changes}} rows. Include symbol and alert name or id on every row.
4. Wait for my "confirm" before producing the final list. Dry-run is the default.

Guardrails

• All proposals must follow verbatim user rules with zero AI discretion on which levels matter.
• Maximum changes per run; dry-run by default; confirmation required.
• Every alert must carry a note explaining why it exists; the agent must not create new alerts.
• Explicit warning each run: data is sent to external AI; do not use for any alert tied to live positions or stops.
• Log every proposed change with a before/after diff.

What can go wrong

The weekly table is easy to rubber-stamp. In tests the agent flagged intentional open-ended weekly levels as stale because they had no expiry, and a bulk confirm would have deleted levels still in the swing plan. The working rule: never auto-apply, exempt alerts whose note contains a keep-until date, and keep {{max_changes}} small.

Source and references