4 ways to connect Facebook Public Data to Claude in 2026 (the easy way)

Connect Facebook Public Data to Claude with MCP

For this tutorial we’re going with the MCP method. Here’s a quick explainer of what MCP is and why it’s the best path for Facebook Public Data.

The full setup takes under 5 minutes and breaks into three moves: connect Facebook Public Data to Porter, point Claude at the Porter MCP, and ask your first question.

1. Connect your Facebook Public Data data to Porter

Porter sits between Meta’s Graph API and Claude. It handles OAuth, rate limiting, pagination and all the plumbing so Claude only ever sees clean, structured data.

Optional: enable automatic BigQuery storage if you’re connecting multiple pages with large data volumes. This keeps Claude’s responses fast even at scale.

2. Connect the MCP to Claude

Porter’s MCP URL is what you paste into Claude. Once added, Claude can query Facebook Public Data data on demand in any conversation.

Go to claude.ai and click the + icon in the chat input to open the tools menu.

In the menu that opens, hover over Connectors and click Manage connectors.

In the Connectors panel, click the + button at the top of the list to start adding a new connector.

Pick Add custom connector from the dropdown that appears.

A dialog opens with the name and URL fields. Type Porter in the first field to name the connector.

In the second field, paste https://mcp.portermetrics.com/mcp. Leave the advanced settings alone.

Click Add at the bottom right of the dialog. Claude opens a sign-in window — use the same Google account linked to your Porter workspace and approve access.

Once the authorization finishes, you’ll see Porter’s read-only tools appear in the connectors panel. You’re ready to start asking questions.

For a fuller walkthrough with screenshots at every step, see the Porter MCP tutorial.

3. Start building questions and dashboards

With Porter connected, open a new Claude chat and ask anything about your Facebook Public Data in plain English. Claude calls Porter behind the scenes, pulls live data from Meta, and answers with tables, charts, or summaries.

Try one of these to verify the setup is working:

For a full catalogue of copy-paste prompts organized by use case (competitive intelligence, brand health, content benchmarking, cross-channel), jump to the prompts section below.

Alternative ways to connect Facebook Public Data to Claude

MCP is the path we just walked through — and the one we recommend for most marketers. But it’s not the only way to get Facebook Public Data data in front of Claude. The most common alternatives are Facebook Public Data’s direct API (or its official MCP if it has one), a live Google Sheets bridge, and BigQuery for scale. Each has its trade-offs — pick the one that fits how your team already works.

• 🔌 Facebook Public Data’s direct API (or official MCP) — Talk to Meta’s Graph API yourself, or install the official Facebook Public Data MCP (if one exists). Maximum control, but you handle auth, rate limits and pagination — and you only get one source.
• 📊 Google Sheets — Live Sheet or one-off CSV upload. Auditable, familiar, faster for big exports — but aggregation happens in the Sheet, not the API.
• 🗄️ Google BigQuery — For large pages or agencies running multi-page analysis. BigQuery aggregates; Claude only queries pre-built summaries.

Via Facebook Public Data’s direct API (or official MCP)

If you’re building a product around Facebook Public Data — or you’re a developer who’d rather own every layer of the integration — the most direct path is talking to Meta’s Graph API yourself, or installing the official Facebook Public Data MCP (if one exists). Facebook does not publish an official MCP server, so this means writing Graph API calls directly in Claude Code or in your own scripts. You’ll need to follow Meta’s rate limits & quotas and request a Developer Token / API access where applicable. Either way, you skip Porter entirely and call Meta from your own code or from Claude Code with raw HTTP requests.

Via Google Sheets (live Sheet or manual CSV)

If your team already lives in Google Sheets — or you want a paper trail before Claude touches anything — feed Facebook Public Data into a Sheet, then let Claude read the Sheet. You can automate the Facebook Public Data → Sheets pipeline with Porter so it refreshes daily, or do one-off CSV exports from Facebook Public Data’s native UI for static analysis.

Via Google BigQuery (for scale)

This is the path most people overlook — and it’s the one that saves you when your Facebook Public Data page gets serious. A single large page or an agency managing 10+ pages will hit API rate limits and latency problems querying Claude directly. Claude will literally tell you it’s taking too long or timing out on big pulls.

BigQuery fixes that. You load Facebook Public Data data into BigQuery tables on a schedule, then connect BigQuery to Claude — either through a BigQuery MCP or via Claude Code with SQL queries. Instead of asking Claude to pull raw Facebook Public Data data, you let BigQuery aggregate into small, optimized tables, and Claude only queries the summarized output. Scale problem solved.

Connecting Facebook Public Data to Claude Code

Most marketers lump Claude and Claude Code together and miss the biggest advantage of the entire MCP ecosystem. They’re not the same tool — and the difference matters enormously once you start working with Facebook Public Data data seriously.

What Claude Code unlocks that Claude alone cannot

This is where the MCP ecosystem pays off most. Because Claude Code can combine Porter’s MCP with other MCPs — Firecrawl for web scraping, Airtable for structured data, Notion for wikis, Vercel for deployment, Slack and Gmail for delivery — you’re no longer querying data. You’re building tools.

🛠️ Build your own competitive intelligence dashboard

Feed Claude Code your Facebook Public Data targets and goals — Page Likes targets, engagement rate goals, follower growth thresholds — and ask it to generate a custom competitive intelligence dashboard for each client. It builds the HTML, pulls live data, deploys to a URL. No Looker Studio embed to break when the vendor changes pricing, no template constraints. The dashboard updates automatically because it queries Porter’s MCP on every page load.

🔍 Full competitor + performance monitoring

Combine your own Facebook Public Data performance from Porter with competitor public pages and their engagement metrics scraped via Firecrawl. Claude Code stitches both into a weekly competitive intelligence report — your numbers next to their post frequency and reaction patterns, with an LLM summary on top of what changed week over week. Runs on cron, lands in your inbox every Monday morning.

📚 Internal marketing wiki with live metrics

Use Airtable or Notion as the schema, Porter as the data source. Claude Code keeps every page populated with current Page Likes, Page Followers, and Talking About Count for every page — no stale screenshots, no copy-paste from Excel. New hires read one wiki entry and have full context on a client’s account.

🔔 24/7 alerts on page engagement drops, follower loss, and negative reaction spikes

A Claude Code routine on cron pulls Facebook Public Data via Porter, evaluates thresholds — Page Followers drop below target, Talking About Count falls 20% week-over-week, negative reactions spike 2× — and pushes Slack or Gmail alerts the moment something crosses the line. You stop checking dashboards reactively; the dashboard checks itself and tells you when to look.

Use cases — what you can actually do once Facebook Public Data is connected to Claude

Getting the connection right is half the battle. The real value shows up in what you do next. Here are the use cases Porter users build around their Facebook Public Data data — from simple Q&A to full client-facing workflows.

1. Chat and ask questions directly

The simplest use case — and still the one 80% of marketers start with. Open Claude, ask a question, get an answer grounded in live data.

It’s the fastest way to replace a daily Facebook Page Insights check-in. But chat is table stakes — the interesting use cases come next.

2. Blend Facebook Public Data with your marketing stack data (Meta Ads, Shopify, HubSpot)

This is where a 360° view gets real. When you connect Facebook Public Data and your marketing stack (Meta Ads for paid campaigns, Shopify for e-commerce, HubSpot for CRM), Claude can map public pages to actual engagement insights and competitive intelligence — using page names, post IDs, and timestamps — and give you competitive benchmarking that no platform-side number can.

Claude handles the page names and timestamps mapping and joins. You get a client-ready competitive benchmarking report that no single platform can generate on its own.

3. Automated alerts and notifications on Slack or Gmail

With Claude Code you can turn Facebook Public Data monitoring into a routine that runs on its own. Hook Porter’s MCP (for the data) together with a Slack or Gmail MCP (for delivery), then write a Claude Code scheduled task that pulls performance every morning and pings you only when something actually needs attention.

No dashboards, no daily check-ins. The report comes to you — and only when it matters.

4. Client-ready presentations with live data (Gamma, HTML, PDF)

A common agency pain: you send clients a Looker Studio link — and you spend an hour explaining a broken dashboard. With Claude you can build the presentation itself — as a Gamma deck, a custom HTML page, or a PDF — populated with live numbers each time.

The presentation becomes a delivery artifact you send to the client, not a dashboard that depends on another tool staying up. No broken iframe, no login prompts, just the content.

Facebook Public Data fields and metrics you can query with Claude

Before you start writing prompts, it helps to know what data is actually available. Porter MCP gives Claude access to 156 Facebook Public Data fields and metrics across every reporting level, plus breakdowns by post type, date, and page category. And the same MCP URL also unlocks 25+ other sources — so Claude can blend Facebook Public Data with Google Ads, GA4, Shopify, HubSpot and more in a single prompt.

Prompts you can copy-paste today

1. For agencies

Agencies need competitive intelligence at scale, client-ready deliverables, and anomaly detection across multiple monitored pages.

2. For brand teams

Brand teams focus on diagnosing performance shifts, optimizing content mix, and segmenting post behavior by time or format.

3. For creators & DTC

Creators and DTC brands use Public Data to reverse-engineer viral content patterns, track their own page growth, and build weekly content recaps.

4. Cross-channel

Cross-channel marketers blend Facebook Public Data with other connectors to connect organic social signals to paid, commerce, or web outcomes.

How to use Claude Code for Facebook Public Data without getting banned

This scenario is representative of the most common “failure mode” marketers face with Facebook Public Data: not a ban, but a silent data cutoff mid-analysis. The cost is operational — a competitive intelligence workflow stalls, a client report is delayed, or a campaign decision gets made with stale data. Unlike authenticated connectors (Meta Ads, Facebook Page Insights) where your ad account or page admin status could be at risk, Public Data’s read-only nature means the ceiling is always throttling, never suspension.

Meta’s rate limiting is quota-based and pattern-based, not tool-based. Meta doesn’t ban or suspend accounts because you used Claude, an MCP server, or Porter’s connector. It throttles API access because of how the underlying Graph API was consumed: bursty parallel requests, repeated polling of the same page endpoints, or exceeding the per-app call budget. Read-only access to public page data is inherently safe from a policy perspective — Meta’s enforcement model (error code 32, HTTP 429) is designed to protect infrastructure, not punish users. Write operations, app-review bypasses, or scraping automation are the behaviors that escalate beyond throttling into app-level restrictions. For Porter MCP users, the relevant boundary is simple: stay within the platform-managed request budget, and data flows continuously.

The two ways to burn through your Facebook Public Data quota

After reviewing official docs and community threads, two patterns come up again and again.

Both behaviors trigger temporary throttling. If you want to use Claude for Facebook Public Data safely, batch your requests and treat the data as periodic snapshots, not a live feed.

The 5-rule scaling protocol

Based on Facebook Public Data’s documented rate limits and quotas and the behaviors that have actually caused throttling — not guesswork:

• Batch your page requests. Stay under 4,800 calls per engaged user per 24-hour sliding window. Facebook’s page-level rate limit allocates 4,800 calls per engaged user per 24 hours for page tokens. A single “analyze all my competitors” prompt can burn this in one session if it fans out to 50+ pages with multi-field requests. Porter MCP enforces per-page request batching and automatic backoff when X-Page-Usage headers approach 80%. Ignoring this limit means incomplete data mid-analysis — some pages return metrics, others return nulls. — Source: Facebook Developers Blog — Page-Level Rate Limits, June 2016
• Respect the 200 calls/hour per user app-level ceiling. At the app/platform level, Facebook allocates 200 calls per hour per user (where “user” is the app-scoped identity). Porter MCP manages this pool across all connected users, but individual heavy users can still consume disproportionate quota. If you share a Porter workspace with a team, coordinate large audits rather than having three analysts run competitive reports simultaneously. Exceeding this triggers error code 32 and a cooldown period. — Source: Facebook Developers — Platform Rate Limiting Overview
• Never exceed 100% on X-App-Usage or X-Page-Usage headers. Facebook returns usage percentage headers with every API response. 100% means you are throttled. Porter MCP reads these headers and pauses requests when any header exceeds 80%, but custom scripts or manual API calls (e.g., via Claude Code with raw curl) can ignore them. If you build custom tooling on top of Porter’s data, implement the same 80% pause threshold. Ignoring headers is the #1 cause of “my data stopped flowing” reports. — Source: Facebook Developers — Rate Limiting Headers
• Limit Marketing API write operations to 100 requests per second. This rule applies primarily to Marketing API (ads management) rather than Public Data read endpoints. Facebook’s Marketing API enforces 100 requests per second for write operations. Since Porter Facebook Public Data is read-only, this limit is not directly relevant — but if you blend Public Data with Meta Ads data in the same MCP session, be aware that write-heavy workflows on the Ads side can indirectly throttle the shared app pool. — Source: Facebook Developers Blog — Rate Limit Console, January 2019
• Space requests to 1 call per second per app for sustained workloads. For long-running or background sync jobs, Facebook recommends 1 API call per second per app as a sustainable baseline. This is conservative for interactive MCP use (where a single Claude conversation might make 10–20 calls in 30 seconds), but it matters for automated exports or scheduled competitive tracking. Porter MCP’s default pacing stays well under this threshold for interactive use; only custom automation scripts need explicit pacing. — Source: Facebook Developers — Platform Rate Limiting Best Practices

• Read-only by default: The Facebook Public Data connector never makes write calls. This eliminates the entire class of policy violations that trigger app-level restrictions.
• Automatic rate-limit backoff: Porter reads X-App-Usage, X-Page-Usage, and X-Business-Use-Case-Usage headers on every response. When usage exceeds 80%, the MCP pauses and retries with exponential backoff rather than hammering the API.
• Per-account request batching: Large competitive analyses are automatically chunked into smaller page groups, spread across time windows, and cached to avoid redundant calls.
• No user-facing credentials: Because users don’t hold Facebook API keys, there’s no token to leak, no app review to fail, and no developer account to suspend. The risk surface is entirely on Porter’s infrastructure — which is monitored and scaled to stay within Meta’s good-standing thresholds.

That’s the behavior Meta’s automated systems handle gracefully: predictable, read-only, header-respecting traffic from a managed platform. Not the bursty, unauthenticated, or scraping-adjacent patterns that trigger throttling or blacklisting.

Frequently asked questions