Automation at a glance

What it does: Keeps sales battlecards current with agent-drafted, human-approved updates

Tools: Visualping (monitoring + MCP/API) + Claude Code (agent) + the doc where your battlecards live

Workflow: Competitor page changes -> monitor fires -> agent drafts the row, date, and log line -> you approve -> card updated

Setup time: ~20 minutes | Ongoing effort: ~2 min per alert

This is one of the highest-payoff Claude Code workflows we run: competitor pages feed monitors, monitors feed the agent, the agent drafts battlecard updates, and a human approves every line before it ships. You leave with the exact prompt, built on real tool calls. No glue code required, and nothing reaches your reps without your initials on it.

Why battlecards are the right first agent workflow

Battlecards decay by design: they're snapshots of competitors who change their pricing and positioning without telling you. Our sales battlecard template attacks that with two mechanics, a Last verified date on every claim and an Update log that records what changed. The mechanics work, and they create a recurring chore: someone has to notice the change, rewrite the row, bump the date, and log the entry.

That chore has the three properties of a good agent task. The trigger is machine-readable: a Visualping alert arrives with the before-and-after screenshots, an importance flag, and a plain-English summary of what changed, written by Visualping AI. The edit is structured: one row, one date, one log line, in a document with a fixed shape. And the quality gate already exists: the template's Verified by column was always a human signature, so the approval step isn't something you bolt on for the AI era. It was the design.

Agent drafts, human signs. That order is the whole workflow.

What you need before you start

Three things, all of which the free tier covers:

• A Visualping account. The REST API and MCP server are available on every plan, including free, and there is no separate API quota: calls draw on the same monthly checks your plan includes. A free account's checks are enough to watch a handful of competitor pages and test the loop end to end.
• A battlecard with dates in it. Any format works if each claim carries a Last verified date and the card has an Update log. Ours is free to copy.
• Claude Code with the Visualping connector. Setup is a few minutes; our guide to monitoring websites from Claude Code covers connecting the MCP server, authenticating, and the full tool list. This post assumes that part is done and gets straight to the workflow.

Step 1: put monitors on the pages that feed each card

Each battlecard runs on about four pages per competitor: pricing, homepage positioning, the product or release-notes page, and their comparison page if they keep one. These are the same public pages where a rival's competitive advantage shows up and gets tested, which is why they're worth an agent's attention in the first place. Create a competitive monitoring watch on each, and select just the section that matters (the pricing table, not the cookie banner) so the alerts you hand the agent are worth reading.

Then do the one thing that makes the automation clean: tag every one of these monitors battlecard. Visualping's monitor list can be filtered by tag, which means the agent can find exactly the monitors that feed cards and ignore everything else you watch.

Step 2: give Claude Code the workflow prompt

Paste this into the project's CLAUDE.md file (or save it as a slash command). Every tool named in it is a real Visualping MCP tool, and the field names match what the server actually returns.

# Battlecard maintenance

When I say "update the battlecards":

1. Call describe_user and note the workspace id for our competitive
   intelligence workspace.
2. Call get_monitors with tag "battlecard" for that workspace to list
   the monitors that feed our cards.
3. For each monitor, call get_timeline with level "important", with
   "from" set to the most recent date in that competitor's Update log.
4. For each event, read the changeSummary and compare the previous and
   current screenshots. Then draft, against the matching battlecard:
   - the affected row, rewritten to reflect the change
   - a bumped Last verified date for that row
   - one Update log line: date, what changed, source URL
5. Present every proposed edit as a before/after diff, grouped by
   competitor. Flag anything you are not confident about.
6. Apply nothing until I approve. The Verified by column is mine to
   initial, never yours.

Run it with a single message: "update the battlecards." The agent pulls only important-level events since each card's last update, reads the AI summary on each change, and comes back with a stack of proposed edits. On a quiet week that's an empty report, which is its own kind of useful: the dates can be bumped with confidence.

Two details in the prompt earn their place. Filtering the timeline by the Update log's own last date means the card's history drives the query, so nothing gets missed between runs and nothing gets re-reported. And the importance filter means the agent reads the changes Visualping AI flagged as meaningful rather than every font tweak and date stamp.

Step 3: review, correct, and sign

The agent's draft arrives as a diff: old row, proposed row, the date bump, the log line. Your job takes about two minutes per alert and has three parts. Check the proposed row against the change summary and the screenshots (the agent occasionally reads a promotion as a price change, which is exactly the kind of misread a human catches in seconds). Correct anything off. Then initial the Verified by column and apply.

Resist the temptation to skip the review on quiet edits. A battlecard claim gets repeated by a rep on a live call, in front of a prospect who may know the competitor's pricing better than anyone in your building. An unreviewed auto-update is precisely the kind of silent change this whole system exists to catch. The agent removes the patrol work and the typing; the judgment stays expensive because it's the part that's worth something.

This page practices what it describes: an agent drafts the quarterly refresh of our own battlecard guide, and a human signs the log before anything ships.

Variations

REST API and webhooks, for code-first stacks. Everything above works over plain HTTP if you'd rather script it than chat it. Webhook deliveries carry the same essentials as the MCP timeline (the summary, the importance flag, the added and removed text), so a small script can file draft edits into a queue and a reviewer can work through them in batches. Our website monitoring API guide covers authentication and the endpoints.

Other agents. The workflow has nothing Claude-specific in it. Codex or any assistant that speaks MCP runs the same loop with the same prompt, adjusted to its instruction format.

Tighter cadence for one competitor. During a rival's launch week, run the same prompt scoped to one tag ("battlecard-northstar") daily instead of weekly. The query shape doesn't change; only the tag does.

What breaks, and the fixes

Too many alerts reaching the agent. Almost always a whole-page monitor on a busy page. Re-select a smaller area, and let the importance filter do its work; the agent should see the changes that matter, not the rotation of a testimonial carousel.

The agent misreads a change. That's the approval gate doing its job, and it's worth logging: when a misread repeats, add a line to the workflow prompt ("treat strikethrough prices as promotions, never as price drops") and the drafts improve from then on.

Check budget runs hot. Monitoring spend is frequency times pages. Pricing pages earn daily-or-faster checks; positioning pages are fine weekly. Trim frequency before trimming pages, since a missing page is a blind spot but a slower check is only a delay.

Frequently asked questions

Can AI keep battlecards up to date automatically?

AI can draft battlecard updates automatically; it shouldn't apply them automatically. The reliable pattern is a monitoring layer that detects competitor page changes, an agent that drafts the affected rows and log entries, and a human who approves each edit. Claims that sales reps repeat on live calls need a person's sign-off behind them.

What are good MCP use cases for competitive intelligence?

Change-triggered workflows are the strongest fit: an agent pulls important-level change events from monitored competitor pages, reads the AI summaries, and drafts updates to battlecards, positioning docs, or win/loss notes. MCP suits these because the agent needs live, structured data (what changed, where, when) rather than a static export.

Do I need the REST API or the MCP server?

Pick by interface. The MCP server fits agent-driven, conversational workflows like the one in this guide. The REST API and webhooks fit scheduled scripts and pipelines. Both are included on every Visualping plan with no separate API quota; calls draw on your plan's normal monthly checks.

Will this work with agents other than Claude Code?

Yes. The workflow uses standard MCP tool calls, so any assistant that supports MCP servers can run it, including Codex. The prompt transfers as-is; only the file or command format where you store it changes between tools.

How much does the monitoring cost?

The free plan includes 150 checks per month across 5 cloud monitors, plus full API and MCP access, which covers one competitor's core pages at a weekly cadence. Paid plans scale by checks and pages. Spend is frequency times pages, so the lever is checking each page as often as it actually changes, and no more.