feat(policy): Propagate Tool Annotations for MCP Servers - #20083
Conversation
Summary of ChangesHello @jerop, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the policy engine's capabilities by introducing a mechanism to propagate semantic metadata (annotations) from tools to the policy evaluation process. This change allows for more granular and declarative policy enforcement, moving away from hardcoded logic, particularly for Plan Mode. By enabling tools to declare their characteristics and behaviors, the system can make more intelligent and customizable decisions about tool execution, improving both security and flexibility. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a metadata propagation pipeline for tools by adding an annotations property. This allows for more declarative policy rules, as demonstrated by migrating the hardcoded Plan Mode logic for read-only MCP tools to a plan.toml configuration file. The changes are well-supported by updated documentation and new integration tests. I've found one high-severity issue related to the handling of empty toolAnnotations in policy rules, which could cause them to not match as expected.
4ecfe5b to
17b622b
Compare
|
Size Change: +2.46 kB (+0.01%) Total Size: 25.7 MB
ℹ️ View Unchanged
|
Wire MCP tool annotations (readOnlyHint, destructiveHint, etc.) through both policy check paths so declarative TOML rules can match on toolAnnotations. This removes the hardcoded per-tool rule injection in mcp-client.ts in favor of a generic annotation-based rule in plan.toml. Key changes: - Store full annotations on DiscoveredMCPTool and expose via getter - Pass toolAnnotations through scheduler, message-bus, and coreToolScheduler policy check calls - Add toolAnnotations field to ToolConfirmationRequest - Update getExcludedTools() to accept tool metadata for annotation rules - Add annotation-based ASK_USER rule for read-only MCP tools in plan.toml - Sync docs with toolAnnotations support Fixes #19654
17b622b to
7c1d3d1
Compare
Fixes #19654
Followup on #20029