← guides
integration · published 2026-05-04

Why MCP-native matters for AI visibility tools — the Arenza architecture

Anthropic's Model Context Protocol (MCP) is becoming the universal way for AI assistants to talk to external data + tools. Most SaaS products will need MCP servers within 12 months. Arenza shipped MCP-first because the buyer (an SEO/GEO agency) lives in Claude Desktop / Cursor / Claude Code — they want to query brand data without context-switching to a dashboard.

In 2026, "AI-native" went from marketing copy to a measurable shipping requirement: does your product expose its data + actions to AI assistants via MCP, or does it require humans to context-switch to a web dashboard?

Arenza shipped its MCP server in the same sprint as the dashboard — not as a follow-up. This article explains why and how.

Why MCP-first (not MCP-later)

The agency principal — our primary buyer — opens Claude Desktop or Cursor 30+ times a day. They open Arenza's dashboard 1-2 times a day. If the only way to act on Arenza data is the dashboard, we lose 28+ daily interaction touchpoints to "I'll deal with that later when I'm at the dashboard". MCP collapses those 28+ moments into "Claude, what do my client brands look like?"

Building MCP later (post-dashboard) is the wrong order: by the time we'd have shipped MCP, the agency would have already either (a) given up because the dashboard was friction, or (b) built their own API integration. Both are losses.

What the Arenza MCP server exposes

Portfolio + accuracy tools

  • list_brands() — caller's portfolio (id, slug, name, domain, region)
  • get_brand_overview({brand_id}) — AVS, share-of-voice, wrong-claim count, mentions per LLM
  • list_prompts({brand_id}) — tracked buyer questions with per-LLM mention rates
  • get_brand_corrections({brand_id}) — what AI gets wrong: verbatim quote, correct answer, recommended fix
  • get_brand_verified_info / verify_brand_claim / get_brand_discoverability — single-brand verification + visibility lookups

GEO inspection tools (deterministic, no auth)

  • score_geo_article({content}) — 0-100 citability score for a draft; no LLM, runs entirely server-side
  • audit_site({url}) — single-fetch GEO/AEO readiness audit of one live page

On-demand scan (PAT transport)

  • run_brand_scan({brand_id}) — trigger an AI-engine scan; returns a jobId you poll via jobs/get

Architecture overview

The MCP server is built into the Arenza backend — the same Cloud Run service that powers the dashboard and REST API, reachable at mcp.arenza.ai. One deployment, one auth stack, one audit log. Why we folded it in rather than running a separate service:

  • Single source of truth for auth + tenant isolation. The backend already enforces brand access and tenant boundaries. The MCP transport authenticates the caller (OAuth 2.1 + Dynamic Client Registration, or a personal access token), resolves their tenant, and runs every query against a read-only database role — the same boundaries as a portal request.
  • Single cost-budget enforcer for LLM calls. Any tool that invokes an LLM shares one cache and one cost-telemetry surface — no duplicate model clients to drift.
  • Audit log unification. Every call — MCP, portal, or REST — lands in the same access log. Compliance + debugging stay simple.

Transport: HTTP-over-JSON-RPC, not stdio

MCP supports two transports: stdio (Claude Desktop spawns a local process) and HTTP. Arenza ships HTTP-only. Why:

  • Zero install for the agency. Stdio requires shipping a binary or npm package the user installs locally. HTTP just needs the URL. Pasting https://mcp.arenza.ai/mcp into Claude's config is 5 seconds; installing a package is 5 minutes + breaks when their npm cache is weird.
  • Centralized observability. Every tool call hits our infrastructure → we see latency, error rates, who calls what, when. Stdio puts everything on the user's machine; we'd be debugging blind.
  • Future write-tools need rate limits. Stdio runs at user CPU speed; HTTP lets us cap per-user QPS at the edge.

Auth: OAuth 2.1 + DCR, or a personal access token

Two ways in, both live. Claude.ai and Claude Desktop add mcp.arenza.ai/mcp as a custom connector and auto-discover the OAuth endpoints (RFC 8414 + RFC 9728) — Dynamic Client Registration means there's no client_id to provision and no API key to paste. For scripts and CLIs, mint a personal access token at /settings/integrations and send it to /rpc as Authorization: Bearer arn_pat_....

Setup walkthrough

For Claude Desktop / Cursor / Claude Code setup steps, see /guides/use-claude-with-arenza-mcp-server. One config block, restart, you're done.

For other SaaS builders thinking about MCP

Build the MCP server in the same sprint as the dashboard, not as a Q3 add-on. Your buyer is already living in Claude / Cursor; the question is whether they reach for your dashboard or just leave their LLM tab and never come back. MCP is the bridge.