Why Curve MCP Answers in Weeks, Not Rows

Curve MCP answers in completed-week totals instead of row-level events because a row describes one person, a weekly total describes a group, and every answer lands with an AI vendor that your BAA with Curve does not cover. Four rules are built to keep those totals from pointing at anyone: small groups are withheld, counts of people are rounded, names appear only if your organization approved them, and every input that shapes a query is a fixed choice. Curve signs a BAA on every plan; this design protects the hop that BAA does not reach. The price is real: no current week, no breakdowns, no revenue.

Why a row can never leave

A row is a record about one person

A single row in a tracking tool's event table typically holds a timestamp to the second, a visitor or device ID, the page URL (often with its query string), the referrer, the UTM values and the campaign. That is one person's visit, written down.

HIPAA's Safe Harbor method (45 CFR 164.514(b)(2)) lists identifiers that must go before data counts as de-identified, including all date elements except the year, URLs, IP addresses and device identifiers. A typical event row carries several before anyone adds a name.

Deleting columns does not fix it. A row reading only "Tuesday afternoon, weight-loss consult page, spring recall campaign" still points at one visit, and the front desk can hold it against Tuesday's bookings. The problem is the unit: a row is about an individual by construction.

A weekly total is about a group. "45 people booked in the last four weeks" names no one. It turns risky when the group is small, when it can be subtracted from another number, or when its label says too much, and the rest of the design closes those gaps.

The AI vendor sits outside the BAA

Whatever an MCP tool returns lands in the model's context, which means it goes to the AI vendor hosting the model. That holds for any client you connect, whether Claude (desktop, web or Claude Code), ChatGPT, Cursor or another MCP-capable agent.

That vendor is often outside any BAA with you. Anthropic offers HIPAA readiness only on Enterprise plans (Free, Pro, Max and Team cannot enable it), and its own documents disagree on whether Claude Code is covered at all: the BAA page covers it only with zero data retention, while its data-retention docs say Claude Code is not covered under HIPAA readiness. Either way, the assistant is a recipient your team chooses, not a subprocessor covered by your BAA with Curve.

So the output itself must not be PHI. Safe Harbor strips every date element finer than the year, and a week-by-week series is built from dates, so the HIPAA method that fits is Expert Determination (164.514(b)(1)): a qualified expert finds "the risk is very small" that an anticipated recipient could identify someone, and documents the methods and results. HHS guidance says no explicit numerical level of risk universally meets that bar. Our guide to how de-identified small-group rules work compares the two methods in full.

An expert can evaluate a closed set of possible outputs. Nobody can evaluate "whatever the model asks for next." Every rule below follows from that: keep the space of possible answers small enough to test end to end.

Why completed weeks, not days or rolling windows

• Days are where small groups live. One location's Tuesday might hold three bookings from a campaign, and a daily series hands every such cell to the model.
• Rolling windows subtract to a day. "Last 30 days" asked Monday and again Tuesday differs by one day in and one day out, which leaves a one-day fragment that subtraction can recover.
• A week in progress is a rolling window in disguise. It changes daily, and Thursday's answer minus Wednesday's is one day of activity.

So every window ends at the last completed Monday-to-Sunday week and spans whole weeks: last week, or the last 4, 13 or 52 weeks. Windows move once a week, so the smallest slice anyone can subtract is a week. Each window also returns a week-by-week series, and every week must pass the same rules alone and against its window.

A side effect helps reporting: a question asked Tuesday and again Friday covers the same weeks. The cost is freshness. Figures can run up to a week behind the dashboard, which matters little for a weekly budget review and makes this the wrong tool for "did yesterday's launch work?"

Withhold, round, and never let two numbers subtract

Inside a week, small groups still need handling. Each rule answers one question: what could a reader who already knows the clinic's patients do with this number?

• Count people, not visits. The floor is checked on distinct people over the whole window, never visits.
• Withhold rather than blur. A small group comes back marked as below the floor, never as a small number. The identifying fact is that very few people did this, and any small number, rounded or not, still says it.
• Round counts and spend, not delivery. Counts of people and visits are rounded, and so is spend. Clicks and impressions are the platform's own counts of ad delivery and pass through as reported. Cost per conversion is computed from the rounded figures, so dividing spend by cost per conversion gives back only the rounded count already shown, never the exact one.
• Round the same way every time. The same raw count always releases the same figure, so asking twice reveals nothing new. Random noise would change on every call and wear away when averaged across many calls.
• Close subtraction paths. Where one released number sits inside another (visitors and goal completers, adjacent funnel steps, a week and its window), the smaller is withheld when the true gap is small. Even the count of withheld rows is rounded, because "two campaigns withheld" is a clue.

Withholding is lossy, and it hurts small clinics most. A single-location practice running five narrow campaigns may see several withheld in a given week. That is the rule working: those rows describe few enough people to match against the appointment book.

The floor and rounding base belong to a versioned ruleset, not a settings page, and a self-describing tool tells the assistant how figures are withheld, so it can explain a withheld cell instead of guessing.

Why names are allowlisted and visitor text never comes back

Labels: approve, don't scrub

The only strings your organization wrote that ever leave are goal, funnel, step and campaign names. Clinic ad accounts often hold names like "dr lee recall", "march reactivation" or "ref 4412 list", and each can carry a provider's name, a date or a pointer to a patient list.

A scrubber has to recognize every way a person writes a name or a date, and it fails silently on the one it misses. An allowlist needs one decision per name. So a name appears only if the organization approved it; otherwise it reads "(label hidden)". Approval covers that exact name, so a rename hides it again until someone approves the new one.

The uncomfortable part: approval moves the judgment to the clinic, it does not remove it. Approve a campaign named after a provider's surname and that name goes out. Treat approval as a disclosure decision, and rename campaigns that carry names, dates or list references first.

Visitor-set strings: never

UTM values, page paths and referrers are different, because anyone with a link can write them. Think of a thank-you URL carrying the form's email in its query string, a UTM typed by hand into a text message, or a referrer from a patient portal. None of it is returned, in any form.

There is a second reason: a visitor string is text a stranger can place straight into your assistant's context. OWASP describes indirect prompt injection as what happens "when an LLM accepts input from external sources, such as websites or files," and its MCP guidance warns that attackers "encode instructions within tool return values." A UTM value is exactly that kind of source, as our piece on prompt injection in ad data explains.

Why inputs are fixed choices, not free text

Outputs can only be as closed as the inputs that produce them. A connector with free-text filters or custom date ranges lets whoever writes the query aim it: narrow by campaign, then city, then a single date, until the group is one person. Two innocent queries (all campaigns, then all but one) hand back the missing campaign by subtraction. Google's open-source Google Ads MCP server, for example, gives the model a search tool that runs any GAQL query it writes: sensible for an ad account, wrong for patient-adjacent counts.

Free text also flows inward. A staff member who types a patient's name into a filter has put it into a query, a log and the model's context before any rule runs, and a model steered by injected text uses free-text inputs as its steering wheel.

So every input that changes what gets counted is a pick from a short list. The window is one of four. The attribution model is fixed at last touch, and spend, clicks and impressions are each platform's own figures (spend rounded). With fixed inputs, the worst a steered model can do to the numbers is choose a different window.

The only text inputs belong to the "open in Curve" link: your question and, optionally, the person you want to look up. Both are handed to the analyst inside Curve, never run a query and never appear in an answer. The link, for questions that need a person, a page or a breakdown, needs a login, works once and opens the in-app analyst where your BAA applies. Our guide to when to use the connector and when to use the analyst covers the split.

How Curve MCP enforces the rules

Curve MCP puts the rules in the only code path that can produce an answer, then surrounds that path with controls that assume a rule might be wrong.

• Nothing person-level to read. The service runs under its own database role, which cannot read contact details, form answers or journeys, and it checks this every time it starts. A bug in a rule cannot release what the service cannot see.
• Read-only. Tools only, no write actions, so a steered model can ask for a different window but cannot change anything.
• A final guard that blocks. Every response is checked for anything that looks like an email, phone number, ID, date or name, and on a hit, or if the guard cannot run, the whole answer is withheld. Names your organization approved skip its name and date checks, which is why approval is the real disclosure decision. It never trims an answer and sends the rest.
• No log, no answer. Every call is logged, no data returns if the log cannot be written, and calls that returned data are kept for years.
• Access that starts at off. A per-user switch, off by default, and only the clinic's primary user can turn MCP on. Tokens are scoped and expire, issuing one needs a confirmation code, and admins are notified.

What the trade-off costs, and what it buys

A marketing director should see the costs before a demo, not after.

• Freshness. Up to a week behind, never the current week, no custom date ranges.
• Depth. No revenue or ROAS, no form data, and no breakdown by channel, device, region or page.
• Tie-out. Conversions count people once per window, so they will not match a platform's conversion column; weekly rows do not sum to the window total; rounded spend will not match the invoice to the dollar; and rows stop at the campaign, with no ad group or keyword rows.
• Resolution. Withheld rows, most often for small clinics and narrow campaigns, and "(label hidden)" until names are approved.

What the design buys:

• Safety that travels. Each answer is built to be safe before it leaves, so Claude, ChatGPT, Cursor or any other MCP client gets the same protected answer, whatever plan or extra connectors a staff member has open.
• Server-side reconciliation. Each campaign's platform-reported spend, clicks and impressions sit next to the conversions Curve's server-side tracking recorded, with cost per conversion by completed week, and one link opens the full sent, accepted and matched view inside Curve.
• A bounded worst case. The database role, the fixed inputs and the closed answer set each limit what a broken rule or a steered model could release, and a closed set is one an expert can test end to end.

For the questions a clinic marketer asks every Monday (which campaigns convert, what each conversion cost, where the funnel drops), weekly totals are the right resolution anyway.

Frequently asked questions

Is aggregated data automatically de-identified?

No. A count of 3 tied to a service-line campaign and one week can be matched to people by anyone holding the appointment book. Group size, rounding and closed subtraction paths are what make a total safe to release. Our explainer on de-identified, anonymized and aggregated data draws the lines.

If our AI vendor signs a BAA, could the connector return rows?

No. HIPAA's minimum necessary standard (45 CFR 164.502(b)) still calls for "reasonable efforts to limit protected health information to the minimum necessary," and a weekly budget question needs totals, not visits. The answers must also be safe for every session that can reach them, including staff on plans with no BAA.

What does "(label hidden)" mean?

The name was never approved for release, or it was renamed after approval. The numbers under it are unaffected.

Is rounded data precise enough to move budget?

For campaigns big enough to justify moving money, yes: rounding shifts a large count by a few people. Where rounding would matter, the count is usually small enough to be withheld, and a budget call on a handful of conversions was a guess anyway.

Why is there no breakdown by channel or landing page?

Every breakdown multiplies the small cells and the ways to subtract one from another, and page paths and source values are strings visitors can write. Those questions go through the "open in Curve" link instead.

Where to start

Before anyone connects an assistant to ad data, list the questions your team asks every week and mark which truly need rows. Few will. Then rename any campaign, goal or funnel step carrying a provider's name, a date or a patient-list reference.

To see weekly answers in an assistant with small groups withheld and people counts rounded, book a Curve MCP demo. For the tracking, attribution and signed BAA underneath it, start at curvecompliance.com. To judge any other connector, use our HIPAA-safe MCP server checklist.

Reviewed September 2026. Describes ruleset v1 of the connector. HIPAA citations are to 45 CFR 164.502(b) and 164.514(b); Anthropic coverage is per its published BAA and data-retention pages.