gemini-connector-agent

A Gemini agent that triages Fivetran connector health, quotes verbatim error codes, and recommends the exact remediation step from the sync history. Apache 2.0.

Comment

Inspiration

Your data team has 47 Fivetran connectors. Three of them are broken right now. The Slack thread is full of guesses: is it Salesforce throttling, did someone rotate a token, is the destination warehouse paused. The actual error message is sitting in the Fivetran API two clicks away. The agent reads it for you.

What it does

gemini-connector-agent treats every "what's wrong with my pipelines?" question as a connector-health triage. The agent walks the Fivetran MCP tools in order:

  1. list_connectors for an at-a-glance status of every connector
  2. get_connector_sync_history to confirm a failure is recurring (not transient)
  3. get_connector / get_destination for the full details on the broken one

The output is structured: which connector is broken, the verbatim error code, the count of recent failed runs, the root cause grounded in the tool output, and the exact next step the team should take.

How we built it

  • Google Cloud Agent Builder (ADK) for the agent framework. The whole agent fits in six lines of ADK: one LlmAgent, one McpToolset, a Gemini model, and a system prompt that defines the triage workflow.
  • Gemini 2.5 Flash on Vertex AI for reasoning.
  • Fivetran MCP server for tools. The agent talks to the official fivetran/fivetran-mcp tool surface. A stub MCP server ships in the repo with five canned connectors (Postgres, Salesforce, Stripe, GitHub, Zendesk) across two destinations (Snowflake, BigQuery), one of which (Salesforce) is in a known-broken state with a realistic recurring API_DISABLED_FOR_ORG failure. Set FIVETRAN_API_KEY + FIVETRAN_API_SECRET and the same agent code targets a real account via uvx from the official GitHub repo.
  • Streamlit for the dashboard.
  • Cloud Run for hosting.

Challenges we ran into

The first version of the system prompt let the model paraphrase the error message instead of quoting it verbatim. The fix was an explicit "quote error messages and codes verbatim" instruction. Subsequent live runs reproduced the full remediation text from the Salesforce API exactly as it appears in the canned tool output, including the path "Salesforce Setup, Profiles, System Administrator, Administrative Permissions".

Accomplishments that we're proud of

  • A real Vertex AI Gemini call walked the Fivetran tools, identified salesforce-main as broken, quoted the API_DISABLED_FOR_ORG error verbatim, cited 5/5 recent runs failed, and recommended the exact remediation step from the error message.
  • 13 passing tests cover the stub server's tool responses and the agent wiring.
  • This is the sixth and final entry in the GCRA partner-track sweep, completing all six MCP integrations: Dynatrace, Arize Phoenix, MongoDB, Elastic, GitLab, Fivetran. All six agents share the same LlmAgent + McpToolset shape; the MCP protocol carried the abstraction every time.

What we learned

A connector-health agent works best when its job is to read and route, not to invent. Verbatim quoting of error messages is the most useful thing it can do, because the remediation step is almost always already in the error text. The data team just needs the error surfaced fast.

What's next for gemini-connector-agent

  • A "recurring vs new" classifier so the agent flags connectors that broke today differently from connectors that have been broken for a week.
  • Cost-spike detection via the monthly active rows field, paired with sync frequency.
  • A scheduled morning report that emails the data team every weekday at 8am with a triage summary of any non-active connectors.

Built With

  • agent-development-kit
  • data-pipelines
  • fivetran
  • fivetran-mcp
  • gemini
  • gemini-2.5
  • google-cloud-agent-builder
  • google-cloud-run
  • mcp
  • python
  • streamlit
  • vertex-ai
Share this project:

Updates