Tennsa in Gemini Enterprise

Gemini Enterprise lets a Google Workspace administrator add an outside MCP server themselves, so everyone in the organisation can ask Gemini about the business and get the answer out of Tennsa. This page is the setup, field by field, plus what the connection can and cannot reach and what each failure actually means. It takes about ten minutes, and only an administrator can do it. If you use Claude or ChatGPT instead, the connector documentation covers those.

Before you start The settings Setting it up The one box people miss What it returns If it does not work Support

Before you start

A Tennsa account with sources connected. The connection reads what Tennsa has already computed; it does not connect anything itself. If nothing is connected to Tennsa yet, Gemini will get honest empty answers.
Gemini Enterprise, not the Gemini app. This is the Workspace product where an administrator adds a custom MCP server as a data store. The consumer Gemini app has its own separate custom-apps feature and is not what this page describes.
Administrator access to add a data store in Gemini Enterprise.
A client id and client secret from us. Gemini Enterprise does not register itself the way Claude and ChatGPT do - it asks you to paste credentials for an application you have registered, and both fields are required. Email info@tennsa.com from the address on your Tennsa account and we will issue them. Everything else on this page is below.

The settings

These are the values the Gemini Enterprise console asks for. Copy them exactly.

Field	Value
MCP server URL	`https://tennsa.com/api/v1/mcp`
Authorization URL	`https://tennsa.com/oauth/authorize`
Token URL	`https://tennsa.com/oauth/token`
Scopes	`mcp offline_access`
Client ID	Request from info@tennsa.com
Client Secret	Request from info@tennsa.com
Enable PKCE Support	Tick this box. See below - it is the one setting that will stop the connection working if you leave it as it comes.
Authorization URL Parameters	Leave empty.

Paste the authorization URL exactly as it is, with nothing after it. Gemini Enterprise adds the standard OAuth parameters itself, so a URL with a query string on the end will not work. That is what the separate parameters field is for, and this connection needs nothing in it.

Transport is Streamable HTTP, which is what Gemini Enterprise supports and what Tennsa serves. There is nothing to choose.

Setting it up

Email info@tennsa.com for the client id and secret, from the address on your Tennsa account.
In Gemini Enterprise, add a data store and choose the custom MCP server type.
Enter the MCP server URL above.
For authentication choose OAuth 2.0, then fill in the authorization URL, the token URL, the scopes, the client id and the client secret from the table above.
Tick Enable PKCE Support.
Save. Gemini Enterprise will send you to tennsa.com to sign in to your Tennsa account and approve the connection. The approval screen names the application asking and states what the connection does and does not reach; read it, then press Allow.
Ask Gemini something only your business can answer, for example "what does my Tennsa briefing say this morning?". If it comes back with your findings, you are done.

Gemini Enterprise is registered with Tennsa as its own application, separate from Claude and from ChatGPT. An approval granted to one of them cannot be used by another, and removing one leaves the others working.

The one box people miss

Read this

Tennsa requires PKCE, and in Gemini Enterprise it is an optional checkbox that is not ticked for you. PKCE is a standard that ties an authorisation to the software that asked for it, so a code intercepted on the way back cannot be used by anyone else. Tennsa requires it of every application, with no exception for one that also holds a secret, because one rule that always applies is worth more than a rule with a list of cases.

If the box is not ticked, the approval fails the moment you are sent to Tennsa - usually as a bare authorisation error back in the console, with nothing to say why. Tick Enable PKCE Support and try again.

What it returns

Everything reachable through this connection is read-only. Nothing Gemini can call changes a record, connects or disconnects a source, or moves money. The one thing a call can spend is an Investigate credit, on the consultant tool below, and it is the only tool that spends anything. The tools are the same six the connector documentation describes in full: the current briefing, which sources are connected and whether Tennsa can actually read them, recent account activity, the five business areas, what Tennsa recorded over a period, and one question to Tennsa's own consultant.

Reaches

The computed findings: headline, plain-text body, severity, category, which sources contributed and the suggested action.
Which sources are connected, and for each one whether the last run could read it.
The account activity log and the business-area summary.
What Tennsa recorded over a date range, including your own invoices, bills, credit notes and payments as it observed them - with a count of the days in that range it could not read, so a day nobody looked at is never reported as a quiet day.
A consultant answer grounded on your connected accounting, payments, commerce, stock and CRM sources. This is the one thing here that costs something: each answered question uses one Investigate credit from your monthly allowance - the same allowance the Investigate page spends - and takes ten to thirty-five seconds. A question it declines to answer costs nothing. It is capped at six a minute.

Does not reach

Anything derived from connected email or calendar data - Gmail, Microsoft 365 and IMAP mailboxes. Those findings are withheld by where they came from, the answer says how many were withheld, and a finding whose origin is not recorded is withheld too.
Email or calendar content through the consultant. Those sources are not built into the consultant's grounding on this channel at all, and the answer names the sources it did consult.
The raw data behind a finding - invoice lists, message subjects, sender addresses. The period history is the one exception, and a narrow one: it returns your own documents, never a figure Tennsa has worked out about somebody else.
Credentials of any kind, and every other Tennsa route. An approval issued here reaches the MCP endpoint and nothing else.

Why the email exclusion exists: Google's Workspace API user-data policy restricts passing Google user data, and data derived from it, to a third party. A tool result handed to an AI vendor is such a transfer, so findings computed from mailbox content stay inside Tennsa's own briefing. Microsoft 365 is excluded as a privacy default for the same kind of content. The privacy policy has the detail.

One thing worth telling your users: a briefing has a time on it, and it is the time Tennsa computed it, not the time Gemini asked. The answer carries that timestamp and says which run produced it.

If it does not work

What you see	What it usually is
The approval fails immediately after Gemini sends you to Tennsa, with a generic authorisation error.	Enable PKCE Support is not ticked. This is the common one. See above.
"Unknown application" on the Tennsa page.	The client id is wrong, or has not been issued yet. Check it against the email we sent, and mind stray spaces.
"Unrecognised return address"	Something other than Gemini Enterprise is using the credentials, or Google has changed the address it returns to. Tell us what the page said and we will sort it out.
The token step fails after you press Allow.	The client secret is wrong, or the token URL has something extra on the end. Both come from the table above, exactly as written.
Gemini connects but every tool call is refused.	The Tennsa subscription has lapsed. Sign in at tennsa.com/account and check. Authorising and renewing are deliberately separate, so the connection survives.
Answers come back but say nothing is connected.	Tennsa itself has no sources connected yet, or they need reconnecting. Ask Gemini which sources are connected - the answer names each one and whether the last run could read it.
It worked and then stopped.	The approval was revoked, or the Tennsa password was changed - changing it signs out every connection on purpose. Set the data store up again and approve once more.
Nothing above.	Email us. Every response Tennsa sends carries a request id, and with it we can find the exact call.

To disconnect: remove the data store in Gemini Enterprise, or ask us to revoke the approval. Revocation takes effect on the very next call - nothing is cached.

Support

info@tennsa.com. Tell us you are setting up Gemini Enterprise and roughly when you tried, and we can match it to the request in our logs. Nothing about a tool call is recorded beyond the tool name, its status and counts.

Operated by Tennsa (Pty) Ltd, South Africa. Privacy policy and terms of service.