One prompt, three networks: a weekly competitor brief across Instagram, TikTok, and YouTube on Anysite MCP
Most competitive monitoring dies the same way. You wire up a scraper for Instagram. Then a competitor leans into TikTok, so you add a second scraper with a different login, a different output shape, and its own way of breaking. Then their best-performing content turns out to be long-form YouTube, so now there's a third. Three actors, three auth flows, three schemas, three things to babysit โ and a weekly "brief" that's really just three browser tabs you skim on Monday and forget by Wednesday.
The usual fix is more of the same: one Apify actor per platform, or a Playwright script per site, each pinned to a layout that changes the moment a platform ships a redesign. It works until it doesn't, and the maintenance cost scales with the number of networks you care about โ which only ever goes up.
There's a simpler shape. One typed data surface, one auth, one schema, and a model that does the reading-and-writing-up part you were doing by hand. Here's how a weekly cross-platform competitor brief comes together on Anysite MCP plus Claude โ and, just as importantly, where the line sits between what the API gives you and what the model does with it.
The problem with one-scraper-per-platform
A per-platform scraper stack is fragmented in three expensive ways.
Auth and access. Every network is its own integration. Each new platform is a new credential, a new rate-limit profile, a new failure mode to learn.
Schema. Instagram's "post" and TikTok's "video" and YouTube's "video" come back shaped differently from each tool. Before you can compare anything, you're writing glue code to reconcile field names โ likes here, like_count there, diggCount somewhere else.
Brittleness. Browser automation reads the page a human sees. Change the page, break the script. You don't find out until the Monday brief is empty.
None of that is the actual work. The actual work is: what did our three competitors publish this week, what landed, and what's different from last week. The plumbing is overhead.
The workflow: one typed surface, fan out, synthesize
Anysite exposes every source through the same two-call MCP pattern โ discover to learn an endpoint's params, execute to fetch typed data โ so adding a platform is a new endpoint call, not a new integration. The same shape covers all three networks here.
What Anysite supplies โ typed per-platform data, one auth, one schema:
instagram/user/userโ a competitor's Instagram profile and follower counts (param:user). Setwith_poststo pull recent posts in the same call.instagram/search/search_postsโ posts matching a brand or campaign keyword (params:query,count), each withlike_count,comment_count, andview_countalready typed.tiktok/users/users_videosโ a creator's TikTok videos, newest first (params:user,count), each carryingplay_count,like_count,comment_count, andshare_count.tiktok/videos/videos_searchโ TikTok videos for a keyword or campaign tag (params:keyword,count).youtube/video/videoโ full video details by ID or URL (param:video), and the response includes auto-fetchedsubtitlesโ the transcript comes back in the same call, no separate caption step.
Every one of those returns the same kind of typed object: an item with engagement counts and text you can compare directly. Instagram likes, TikTok plays, and YouTube views land in one consistent shape from one authenticated surface โ the reconciliation glue code disappears.
What Claude orchestrates โ the parts that were manual:
- Fan out. For each competitor, Claude issues the three platform queries in parallel via
execute(). One prompt, three networks, run concurrently. - Diff against last week. Claude compares this run to the previous week's cached results and computes the delta โ new posts, engagement swings, what dropped off.
- Rank and dedup. It surfaces the top-engagement post per platform and collapses the same campaign showing up across networks into one line instead of three.
- Read the long-form. The YouTube transcripts come back as text, so Claude pulls recurring themes out of what competitors are actually saying โ not just the view count.
- Synthesize. It writes the whole thing into one consistent brief, e.g. a per-competitor row of
{platform, post_count, top_engagement_post, transcript_themes[], delta_vs_last_week}.
The division of labor is the point. Anysite turns three messy networks into typed data behind one auth. Claude does the fan-out, the week-over-week diff, the ranking, the theme extraction, and the write-up โ the judgment work, the part that used to be a person with three tabs open.
A non-engineer can drive this
Because both halves are language-shaped, the person assembling the brief doesn't write scraper code. They describe the outcome: "Every Monday, for these three competitors, pull their Instagram, TikTok, and YouTube from the past week, tell me the top post on each, summarize what their YouTube videos are about, and flag anything that changed since last week." Claude maps that to the discover/execute calls; Anysite returns typed data; Claude writes the brief. Schedule the prompt and the brief shows up on its own โ no dashboard subscriptions, no per-platform tools to keep alive.
Adding a fourth competitor is another name in the prompt. Adding a fourth network โ if you cover it โ is another endpoint in the same discover/execute pattern, not another integration to build and maintain.
What's preserved โ and what we're not claiming
This workflow is a rebuild of an Apify community case for cross-platform creator and brand tracking. To be precise about what carries over: what's preserved is the workflow shape โ recurring, multi-platform competitor monitoring synthesized into one output. Anysite plus Claude reproduces that shape on a typed MCP surface instead of a stack of per-platform actors.
What we are not claiming is any specific cost, speed, or throughput number from the original Apify build. We didn't benchmark against it, so we won't borrow its figures. The honest claim is narrow and, we think, the one that matters: the same job that took one scraper per network becomes one prompt over one interface, and the assembly that took a person becomes a step the model runs.
Try the shape
If you maintain a per-platform scraper stack for competitive monitoring, the fastest way to feel the difference is to rebuild one weekly brief. Point Claude at Anysite MCP, name two or three competitors, and ask for a Monday cross-platform summary across the networks you track. Run discover on instagram, tiktok, and youtube to see the typed fields you get back, then let the model handle the fan-out and the write-up.
One auth, one schema, one prompt โ across three networks that used to need three tools.
Further reading: for how the single discover/execute surface scales across 200+ sources, see the companion piece "One surface, 200+ data sources: how Anysite's five MCP tools stay flat as the catalog grows."