-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat: add MCP tool annotations to all PostgreSQL tools #2220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add MCP tool annotations to all PostgreSQL tools #2220
Conversation
Add tool annotations to all 23 PostgreSQL tools to improve LLM decision-making with MCP specification 2025-03-26. Changes: - Add helper functions to tools.go for DRY annotation defaults: - NewReadOnlyAnnotations() for query-only tools - NewDestructiveAnnotations() for data-modifying tools - GetAnnotationsOrDefault() to use custom or default annotations - Add Annotations field to all PostgreSQL tool Config structs - Apply read-only annotations to 22 query tools (list*, get*, etc.) - Apply destructive annotations to postgres-execute-sql tool The helpers reduce per-tool annotation code from 8 lines to 1 line, making future tool annotations cleaner and more maintainable. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Summary of ChangesHello @triepod-ai, 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 improves the integration of PostgreSQL tools with Large Language Models by implementing Machine Coded Protocol (MCP) annotations across all 23 available tools. It also introduces a set of helper functions that standardize and streamline the process of applying these annotations, ensuring consistency and reducing boilerplate code for future tool development. The annotations clearly delineate between read-only and destructive operations, providing LLMs with crucial context for safer and more effective tool invocation. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces MCP tool annotations for all PostgreSQL tools, which is a great enhancement for helping LLMs make better decisions. The addition of helper functions (NewReadOnlyAnnotations, NewDestructiveAnnotations, GetAnnotationsOrDefault) to abstract away the annotation logic is a good design choice that improves code clarity and maintainability. The classification of tools as either read-only or destructive seems appropriate. I have one suggestion to optimize the new helper functions in tools.go to improve performance by reducing memory allocations.
| // NewReadOnlyAnnotations creates default annotations for a read-only tool. | ||
| // Use this for tools that only query/fetch data without side effects. | ||
| func NewReadOnlyAnnotations() *ToolAnnotations { | ||
| readOnly := true | ||
| return &ToolAnnotations{ReadOnlyHint: &readOnly} | ||
| } | ||
|
|
||
| // NewDestructiveAnnotations creates default annotations for a destructive tool. | ||
| // Use this for tools that create, update, or delete data. | ||
| func NewDestructiveAnnotations() *ToolAnnotations { | ||
| readOnly := false | ||
| destructive := true | ||
| return &ToolAnnotations{ | ||
| ReadOnlyHint: &readOnly, | ||
| DestructiveHint: &destructive, | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid heap allocations on every call to NewReadOnlyAnnotations and NewDestructiveAnnotations, you can define package-level boolean variables and reuse their pointers. This is a common optimization in Go for functions that need to return pointers to primitive types and will improve performance by reducing unnecessary memory allocations.
| // NewReadOnlyAnnotations creates default annotations for a read-only tool. | |
| // Use this for tools that only query/fetch data without side effects. | |
| func NewReadOnlyAnnotations() *ToolAnnotations { | |
| readOnly := true | |
| return &ToolAnnotations{ReadOnlyHint: &readOnly} | |
| } | |
| // NewDestructiveAnnotations creates default annotations for a destructive tool. | |
| // Use this for tools that create, update, or delete data. | |
| func NewDestructiveAnnotations() *ToolAnnotations { | |
| readOnly := false | |
| destructive := true | |
| return &ToolAnnotations{ | |
| ReadOnlyHint: &readOnly, | |
| DestructiveHint: &destructive, | |
| } | |
| } | |
| var ( | |
| trueBool = true | |
| falseBool = false | |
| ) | |
| // NewReadOnlyAnnotations creates default annotations for a read-only tool. | |
| // Use this for tools that only query/fetch data without side effects. | |
| func NewReadOnlyAnnotations() *ToolAnnotations { | |
| return &ToolAnnotations{ReadOnlyHint: &trueBool} | |
| } | |
| // NewDestructiveAnnotations creates default annotations for a destructive tool. | |
| // Use this for tools that create, update, or delete data. | |
| func NewDestructiveAnnotations() *ToolAnnotations { | |
| return &ToolAnnotations{ | |
| ReadOnlyHint: &falseBool, | |
| DestructiveHint: &trueBool, | |
| } | |
| } |
|
Closing this PR as the PostgreSQL annotations are included in #2221 which consolidates all remaining tool annotations. |
Summary
tools.gofor DRY annotation defaults (NewReadOnlyAnnotations(),NewDestructiveAnnotations(),GetAnnotationsOrDefault())postgres-execute-sqltoolDetails
This PR adds tool annotations to all PostgreSQL tools to help LLMs make better decisions about tool invocation. It also introduces helper functions that reduce per-tool annotation code from 8 lines to 1 line, making future annotations cleaner.
Helper Functions Added
Tools Annotated
Test plan
🤖 Generated with Claude Code