feat: add support for Google Search grounding as a tool type for Gemini models#1641
Merged
mathetake merged 8 commits intoenvoyproxy:mainfrom Jan 7, 2026
Conversation
Signed-off-by: jamesbuddrige <jxbuddrige@hotmail.co.uk>
8776e6b to
43edc73
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1641 +/- ##
==========================================
+ Coverage 81.04% 81.08% +0.03%
==========================================
Files 147 147
Lines 13341 13363 +22
==========================================
+ Hits 10812 10835 +23
+ Misses 1876 1874 -2
- Partials 653 654 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Member
|
@yuzisun @hustxiayang could you take a look? |
Contributor
|
@jamesbuddrige can you help update the doc here to include the GoogleSearch tool |
aabchoo
reviewed
Dec 22, 2025
Signed-off-by: jamesbuddrige <jxbuddrige@hotmail.co.uk>
366bb1d to
333da3b
Compare
yuzisun
approved these changes
Jan 3, 2026
mathetake
approved these changes
Jan 7, 2026
hustxiayang
pushed a commit
to hustxiayang/ai-gateway
that referenced
this pull request
Jan 13, 2026
…ni models (envoyproxy#1641) **Description** Adds support for Google Search grounding [1] as a tool type for Gemini models, complementing the existing enterprise web search support added in envoyproxy#1526. Enterprise search and Google Search are two different tools in Vertex. See [2] for more details. [1]: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/grounding/grounding-with-google-search [2]: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/grounding/web-grounding-enterprise#overview The implementation translates the google_search tool type to Gemini's GoogleSearch with support for all configuration options: - exclude_domains: Filter out specific domains from search results (Vertex AI only) - blocking_confidence: Set phishing block threshold (Vertex AI only) - time_range_filter: Restrict results to a time window (Gemini API only) Response grounding metadata is already handled by the existing GroundingMetadata field from envoyproxy#1526. **Related Issues/PRs (if applicable)** Related PR: envoyproxy#1526 **Special notes for reviewers (if applicable)** The config structs are prefixed with GCP (e.g., GCPGoogleSearchConfig, GCPTimeRangeFilter) to follow the existing pattern for vendor-specific extensions (GCPVertexAIVendorFields, GCPVertexAIGenerationConfig). --------- Signed-off-by: jamesbuddrige <jxbuddrige@hotmail.co.uk>
hustxiayang
pushed a commit
to hustxiayang/ai-gateway
that referenced
this pull request
Jan 13, 2026
…ni models (envoyproxy#1641) **Description** Adds support for Google Search grounding [1] as a tool type for Gemini models, complementing the existing enterprise web search support added in envoyproxy#1526. Enterprise search and Google Search are two different tools in Vertex. See [2] for more details. [1]: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/grounding/grounding-with-google-search [2]: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/grounding/web-grounding-enterprise#overview The implementation translates the google_search tool type to Gemini's GoogleSearch with support for all configuration options: - exclude_domains: Filter out specific domains from search results (Vertex AI only) - blocking_confidence: Set phishing block threshold (Vertex AI only) - time_range_filter: Restrict results to a time window (Gemini API only) Response grounding metadata is already handled by the existing GroundingMetadata field from envoyproxy#1526. **Related Issues/PRs (if applicable)** Related PR: envoyproxy#1526 **Special notes for reviewers (if applicable)** The config structs are prefixed with GCP (e.g., GCPGoogleSearchConfig, GCPTimeRangeFilter) to follow the existing pattern for vendor-specific extensions (GCPVertexAIVendorFields, GCPVertexAIGenerationConfig). --------- Signed-off-by: jamesbuddrige <jxbuddrige@hotmail.co.uk> Signed-off-by: yxia216 <yxia216@bloomberg.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds support for Google Search grounding 1 as a tool type for Gemini models, complementing the existing enterprise web search support added in #1526. Enterprise search and Google Search are two different tools in Vertex. See 2 for more details.
The implementation translates the google_search tool type to Gemini's GoogleSearch with support for all configuration options:
Response grounding metadata is already handled by the existing GroundingMetadata field from #1526.
Related Issues/PRs (if applicable)
Related PR: #1526
Special notes for reviewers (if applicable)
The config structs are prefixed with GCP (e.g., GCPGoogleSearchConfig, GCPTimeRangeFilter) to follow the existing pattern for vendor-specific extensions (GCPVertexAIVendorFields, GCPVertexAIGenerationConfig).
I'm not completely sure this is the right design pattern for tool options going forward. These fields are necessary to expose the full functionality of the underlying API, but adding vendor-specific config structs to the OpenAI schema does muddy the interface a bit. The alternative would be something more generic (e.g., map[string]any), but that loses type safety. Open to feedback on whether this approach makes sense or if we want to establish a different pattern for future tool configurations.