Connect Gemini Enterprise to Traveler.md

Gemini Enterprise lets an organization admin add Traveler.md as a custom MCP server data store, so people in your organization can have Gemini read their Traveler.md and Trip.md files and keep them updated. This is admin-configured, per tenant, and self-serve (no Google approval needed).

The consumer Gemini app does not support adding custom connectors. This guide is for Gemini Enterprise only. Custom MCP support in Gemini Enterprise is in preview, so the exact screens may change.

Before you start

• You need the Discovery Engine Editor IAM role (roles/discoveryengine.editor) to create the data store.
• The MCP server must use the StreamableHTTP transport. The older SSE transport is not supported. (Traveler.md uses StreamableHTTP.)
• The server must be reachable on a public endpoint. Private Service Connect and VPC Service Controls are not supported in the current preview.

Steps

1. Register Gemini Enterprise as an OAuth client application with your identity provider (for example Okta, Microsoft Entra, or Google).

2. In the Google Cloud console, create a new custom MCP server data store. Enter:

   • MCP Server URL:

     MCP server URL

     https://mcp.traveler.md/mcp

   • MCP Server Description: a short description of what Traveler.md does and when to use it.

3. Configure and name the data connector (set the location / multi-region), then click Create. Wait until the data store’s state changes from Creating to Active.

4. Open the data store and enable the actions (tools) you want available. By default Gemini Enterprise treats every tool call as potentially destructive and asks the user to confirm. For Traveler.md’s read-only tools, the server’s readOnlyHint annotations let Gemini skip that confirmation for a smoother experience.

5. In the Gemini Enterprise app, open the connector and click Authorize to run the OAuth flow as your user; sign in to Traveler.md and approve the scopes.

6. Paste the instruction block below into the agent’s instructions, or send it as your first message.

   Send this to Gemini:

   I use Traveler.md as my travel memory, so my preferences and my trips live in one place I can connect to the travel tools I use. There are two kinds of files, and I manage both on the Traveler.md platform: one profile with my lasting travel preferences, and one file per trip with the details for that trip. You can read and update both through the Traveler.md connector. Follow these rules whenever travel comes up: - Read before answering. For any travel-related request, first read my profile and the relevant trip file. Use what's there, and don't ask me for anything the files already contain. - If you can't reach my files, say so. Don't guess or invent preferences. Tell me the connector isn't responding so I can reconnect it. - Capture durable preferences immediately. When I state a lasting travel preference, even casually with no trip in progress (e.g. "I prefer aisle seats"), update my profile right away, then confirm in one line what changed. Make the actual update, don't just say you will. - Keep one-off details in the trip file. Needs specific to a single trip (e.g. "ground-floor room this time") go in that trip's file, not my profile. For that trip, the trip file overrides my general defaults. - One file per trip. Create a new trip file when a trip takes shape, store the itinerary and ideas in it, and update it as plans firm up. - Keep everything clean. No duplicates, and preserve existing entries unless you're correcting or replacing them. If a new preference conflicts with an old one, replace it and note the change. - Flag the edits that matter. Tell me briefly when you create a trip file or make a significant change, and skip announcing trivial ones.

Troubleshooting

• Scope or revocation change not reflected? Changes can take up to 15 minutes to propagate. The app keeps its current token until then, and picks up the change immediately if it re-authenticates.