A weekend MCP demo can expose three tools over stdio. Operating business ad accounts through AI requires a different architecture — one MCP360 built for Ad Platform MCP and sibling services.
Authentication Boundaries
Production servers separate client auth (your MCP API key authenticates the AI client to MCP360) from vendor auth (OAuth tokens for Meta, Google, HubSpot stored per organization). Keys are revocable; vendor tokens refresh automatically without client involvement.
Tool Execution Pipeline
A typical write tool path:
1. Validate API key and org permissions
2. Parse and schema-validate arguments
3. Run safety policies (budget caps, approval thresholds)
4. Call vendor API with org-scoped credentials
5. Write audit log entry with actor, payload, and result
6. Return structured JSON to the client
Read tools skip approval but still enforce scope and rate limits.
Rate Limiting and Idempotency
Ad APIs throttle aggressively. The server centralizes backoff, quota tracking, and batching so individual AI clients cannot accidentally DDoS your own integrations.
For financial or budget mutations, idempotency keys prevent duplicate execution if a client retries after a timeout.
Observability
Operators need dashboards beyond the AI chat transcript: which tools fired, which accounts changed, which approvals are pending. MCP360's web dashboard complements MCP access for this reason.
Build vs Buy
Teams with dedicated platform engineering can self-host MCP servers per our architecture patterns. Everyone else benefits from hosted servers with compliance and safety already wired — see choosing MCP hosting.
Pair technical architecture with operational policy: budget safety controls for any write-enabled deployment.