What does a Google Analytics MCP server for marketing teams change?
It changes who reads the property and whether the read is recorded. It does not change the numbers.
The situation is familiar. A marketing lead asks ChatGPT which campaigns drove signups last month. Nothing in the chat can answer. An analyst finds an analytics MCP server on GitHub and pastes it into their own client config, with a credential next to it. The question gets answered that afternoon. The company now has one more place a credential lives, and no record of what was read.
MCP is the protocol an AI client uses to list and call tools on a server. A Google Analytics MCP server for marketing teams is therefore a plumbing decision, not an analytics decision. The two things worth deciding are the identity behind each call and the trail it leaves. Everything else in this post follows from those two.
Where the analytics data model ends and the tool list begins
The tool layer does not invent or remove a single dimension or metric. Your analytics vendor's own documentation is the authority on what a report request accepts. It stays the authority after you put a server in front of it. If a dimension is not in the reporting API, no MCP server conjures it.
What the tool layer does decide is three things: what each tool is called, which arguments the model may set, and how risky Elaichi treats the call.
That third one surprises people. For a remote MCP server, Elaichi reads the tier from the tool's own annotations. A tool the server marks read-only counts as a read. A tool the server does not mark read-only or non-destructive counts as destructive. A reporting tool with no annotations is therefore treated as destructive. Someone who can manage the connector lowers its tier, per tool. That is deliberate: Elaichi would rather over-classify a tool it cannot read than guess downward.
Who does the call run as, and why is that the whole question
Every connected-tool call Elaichi runs acts as one specific person, never as the organization. Over MCP that person is whoever approved the OAuth grant behind the client's token. A grant is the standing approval a person gives a named client on Elaichi's own consent screen.
That has a direct consequence for analytics. If marketing should see the property as themselves, each person connects their own account at the analytics vendor. The tools then run on their own connections. A connection someone shares with the team runs on its owner's sign-in instead, for everyone it is shared with. One shared analytics connection is a fine answer when the whole team should see the same property with the same reach. It is the wrong answer when one person's account can see a property the rest should not.
Elaichi serves every organization at one address, https://api.elaichi.ai/mcp. Claude, ChatGPT and Cursor all sign in there. There is no per-team or per-person URL to hand out. The grant behind the token, not the URL, decides which organization and which person a client reaches.
How to bring a remote analytics MCP server under one address
An organization on Gold can add its own analytics MCP server as a connector. The server has to be reachable over public HTTPS and speak MCP over Streamable HTTP. That needs the connector:create permission, which among the built-in roles only Org Owner and Org Admin hold. It is the one permission Elaichi flags as high trust, because a restriction binds the connector, not the host it calls.
In the console it is Connectors, then New connector, then Add remote MCP server. The form asks for a server URL, a name, a slug and a choice for new tools: Automatic, or Review. Sign-in is detected from how the server answers, with options for your own OAuth client or an API token behind Advanced settings. The server URL cannot be changed afterward; a different server means a new connector.
Tools are then discovered per connection, with that connection's own credential, because two members' accounts can see different tools. Three limits matter before you plan: 25 organization-owned remote MCP connectors per organization, 500 tools per connection, and a 4 MiB cap on one tool call's result. A large unsampled export is not a good fit for a chat window anyway.
If Google Analytics is already a connector Elaichi authors and runs for your organization, none of this applies. You connect it from the Google Analytics connector page like any other app. The catalog changes with each sync, so check the connector catalog rather than trusting a number in a blog post; it carries 650+ connectors today. Calls a client makes straight to a vendor's own server, outside Elaichi, are not governed by Elaichi. That is the reason to bring the server inside, and it is why using a vendor's server and running it through Elaichi are separate decisions.
What marketing actually sees in ChatGPT or Claude
They see one app called Elaichi, not one app per analytics property. In ChatGPT's terms it is added as one plugin; in Claude's, one connector.
Inside the tool list, connected tools are never listed one by one, however few there are. The model finds a connected tool with search_tools and runs it with execute_tool, plus run_code where Code Mode is available. So a marketer types a campaign question, the model searches for an analytics tool by name, and calls it. Search is lexical, so concrete words like "report traffic source" beat a full sentence.
Two things follow that people expect to work and do not. A client control that gates individual tool names can only act on execute_tool as a whole, because that one name carries every connected app. Claude, for example, sets a connector's tool permissions to Always allow, Needs approval or Blocked, for a whole connector, a category of its tools or a single tool (Anthropic's connectors article, checked October 2026). Pointed at Elaichi, those settings land on execute_tool, not on one analytics tool.
The second is that Elaichi asks nothing per call over MCP: the grant is the approval. Any confirmation a marketer sees before a call is their own client's prompt. Cursor asks for approval before using MCP tools by default (Cursor's MCP docs, checked October 2026). ChatGPT may show an approval card before a write action, depending on the app's permission setting and the action's context (OpenAI's app permissions article, checked October 2026). Per-app and per-tool control belongs in Elaichi, as restrictions.
Holding marketing to reads, and locking the property
A restriction says which connectors and tools a role or one member may reach. It targets a role or a single member; there is no organization-wide or team target, so a marketing team is governed through the role its members hold.
Two shapes do the work here. Block rules name the tools marketing should not reach, and everything not blocked still passes. Allow rules are stricter, and they catch people out. Once a role carries any allow rule, the allowlist is on. Every connector and tool its allow rules do not name is then blocked for that role. That holds across all connectors, not only the one you had in mind. A role held to an analytics server's read tools by an allow rule therefore needs allow rules for every other app it uses too. To a restriction rule, a remote MCP tool is the resource mcp with the upstream tool name as its method. Every gate runs before the call leaves Elaichi. Role and restriction changes reach every surface within about two minutes.
The second lever is frozen parameters, which Elaichi's console calls locked-in values. Pin the connection into a toolbox entry, an entry being one tool with one account behind it. Freeze the property identifier and share the toolbox at use. Calls through that entry always carry that property. Two caveats are real. The AI can see that a value is frozen and often what it is; it just cannot change it. And the freeze holds only on calls through that entry. Anyone who can use the connection themselves has the same tool unfrozen in their All tools toolbox. Keep the connection unshared and share the toolbox instead. Locking tool arguments covers that pattern end to end.
What the audit log shows after a campaign question
Every connected-tool call that reaches execution writes one row. The row names the acting person, the toolbox the call went through, and the tool's advertised and catalog names. It also records the connector, the connection the call reached and the tool's classification. The last three fields are how approval was given, the surface, and the MCP client's id. The console renders it as a sentence, for example a named person updating a named item through a named connection using Claude.
Three honest limits. Refusals that happen before execution write no row, so a scope refusal or a restricted tool does not appear as a call. Argument values are not recorded, apart from the one path argument that names the object. And Elaichi keeps 90 days of audit history; for longer, export to your own Datadog comes with the Black plan, which is launching soon. What an AI agent audit log must capture goes through the fields one by one.
When marketing does not need any of this
One analyst, one property, their own client, their own account. In that case the analytics vendor's own MCP server is the shorter path and adds no second vendor. The trade is that those calls never pass through Elaichi. There is no central restriction and no shared audit trail of what was read.
The case for one governed address starts when marketing is several people. It also starts when one person's analytics account can reach properties the rest should not. And it starts the day someone asks what the AI read, and when. If you are not there yet, when you don't need an MCP gateway is the more useful read.
For the wider model behind roles, restrictions and grants, start with MCP governance. For the sibling case of a marketing team with its CRM in the same chat window, see HubSpot inside ChatGPT. To connect the client itself, follow the ChatGPT setup.
