Before You Flip the Write-Access Switch

Marketing Academy · Field Work●AI in Marketing

All projects·From: MCP & Connected AI Workflows

CoreAudit· 45 minutes

Yatra Online

Objective: Audit a draft MCP rollout plan for missing guardrails and unvetted community servers before write access or a fourth production connection goes live.

You're revenue operations at Yatra Online, reviewing a draft MCP rollout plan that would connect four tools and let the AI reallocate ad budget automatically, before it goes to the CMO for sign-off.

Score the draft plan against the lesson's guardrail categories and the authentication-hygiene warning, then vet each of the four candidate MCP servers for production readiness.

Before you start

What you'll need

Free path (everything below is enough to finish)

Google Sheets

FreeBuild and score the guardrail-gap checklist

Free, easy to share with the CMO for sign-off

Perplexity

FreemiumResearch each candidate MCP server's maintainer and commit history

Free tier handles a handful of targeted lookups across GitHub and vendor changelogs

The process

2 steps

Step 01 of 02

Guardrail definition before enabling write access

Mistake 3 requires explicit numeric guardrails before write access: a cap on budget reallocated in one action, a conversion floor below which a campaign can't be paused, a segment-size ceiling for automated sends. The authentication-trap callout adds token-hygiene rules for every connected tool.

Yatra Online's draft MCP rollout plan says 'AI can reallocate budget between underperforming ad groups as needed.' What's missing before this goes live?

Google Sheets— Build a guardrail checklist and score the draft plan against each required category

Procedure

List the 3 guardrail categories from the lesson: spend cap per action, conversion floor before pausing, segment-size ceiling before sending
Check the draft plan's language against each category for a specific number, not a vague phrase like 'as needed'
Add the missing authentication-hygiene items: token expiry dates, permission scope per tool, a revocation owner
Rewrite the flagged clauses with real numbers before resubmitting

Sample output

GUARDRAIL GAP AUDIT — Yatra Online MCP Rollout Draft

1. Spend cap per reallocation: MISSING. Plan says 'as needed.' Needs a number, e.g. never move more than 15% of a campaign's daily budget in one action.
2. Conversion floor before pausing: MISSING.
3. Segment-size ceiling before sending: N/A, this workflow has no email-send step.
4. Token expiry tracking: MISSING for all 4 tools.

VERDICT: Not ready for write access.

Healthy

Every guardrail category gets a specific number or an explicit 'not applicable' with a reason.

Unhealthy

The plan is approved with 'as needed' language still in place because no one wrote the numbers down.

What this means

A guardrail without a number is not a guardrail; 'as needed' gives the AI the same discretion as no rule at all.

So what do I do about it?

Symptom	Action	Effort
Draft plan uses 'as needed' instead of a percentage or threshold	Send the plan back with the 3 missing numbers required before resubmission	30 min

YouYou can do this yourself, no engineering access required.

Step 02 of 02

Vetting community MCP servers before production use

Mistake 4 notes the MCP ecosystem grew from roughly 1,000 servers in early 2025 to over 10,000 by March 2026, most community-built and uneven in quality. Check for an official vendor release before connecting anything to production.

Given 4 candidate MCP servers, HubSpot official, Google Ads official, a community-built GA4 connector with 40 GitHub stars, and a community-built email-platform connector with no listed maintainer, which get flagged before connecting to Yatra Online's production account?

Perplexity— Research each candidate server's maintainer status and recent commit activity

Procedure

Confirm which servers are official vendor releases versus community-built
For each community server, check maintainer identity, last commit date, and open issue count
Flag any server with no listed maintainer or no commits in the last 90 days
Recommend a staged connection order: official servers first, vetted community servers second

Sample output

SERVER VETTING SCORECARD
1. HubSpot official MCP server — Vendor-maintained, GA April 2026. CLEARED.
2. Google Ads official MCP server — Vendor-maintained. CLEARED.
3. Community GA4 connector (40 stars) — Last commit 45 days ago, 1 open auth-related issue. CONDITIONAL, monitor before production use.
4. Community email-platform connector, no listed maintainer — FLAGGED. Do not connect to production.

Healthy

The two official servers clear immediately; both community servers get an explicit, reasoned status.

Unhealthy

All 4 servers get approved on the same timeline because 'it's already in the plan.'

What this means

An unmaintained connector with production write access is a single point of silent failure, exactly the authentication-trap risk the lesson warns about.

So what do I do about it?

Symptom	Action	Effort
A candidate server has no listed maintainer	Hold that connection until an official or actively-maintained alternative exists	30 min

EitherYou or a developer can handle this, depending on your access.

Final deliverable

A guardrail-gap audit memo plus a vendor-vetting scorecard for the 4 candidate MCP servers, both ready for the ops team before write access is enabled.

See a reference example

Sample output

TBO Tek — MCP Rollout Guardrail & Server Audit (excerpt)

GUARDRAIL GAPS
1. Spend cap per reallocation: Present, capped at 10% per action. CLEARED.
2. Conversion floor before pausing: MISSING.

SERVER VETTING
1. Google Ads official connector — CLEARED.
2. Community-built supplier-CRM connector, last commit 6 months ago — FLAGGED. Do not connect to production.

Success criteria

You're done when you can:

Correctly identifies every guardrail category missing a specific number
Correctly flags the unmaintained community server and clears both official servers
Recommends a staged connection order rather than approving all 4 at once