-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Add initial support for multi-tool workflows #685
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
Conversation
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.
Pull Request Overview
This PR adds support for multi-tool workflows by introducing four new workflow prompts that provide guided interactions for common GitHub development tasks. The workflows combine multiple existing GitHub tools into structured, conversational flows for more comprehensive automation.
- Adds four new workflow prompts for PR review, notification triage, issue investigation, and issue-to-fix workflows
- Integrates workflow prompts into existing toolsets (issues, pull_requests, notifications)
- Provides guided multi-step processes that leverage existing GitHub API tools
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| pkg/github/workflow_prompts.go | New file containing four workflow prompt implementations with guided conversation flows |
| pkg/github/tools.go | Integration of new workflow prompts into existing toolsets for issues, pull requests, and notifications |
Comments suppressed due to low confidence (4)
pkg/github/workflow_prompts.go:13
- The return parameter name 'tool' should be 'prompt' since it returns an mcp.Prompt, not a tool. This naming is inconsistent and misleading.
func PullRequestReviewWorkflowPrompt(t translations.TranslationHelperFunc) (tool mcp.Prompt, handler server.PromptHandlerFunc) {
pkg/github/workflow_prompts.go:53
- The return parameter name 'tool' should be 'prompt' since it returns an mcp.Prompt, not a tool. This naming is inconsistent and misleading.
func NotificationTriageWorkflowPrompt(t translations.TranslationHelperFunc) (tool mcp.Prompt, handler server.PromptHandlerFunc) {
pkg/github/workflow_prompts.go:92
- The return parameter name 'tool' should be 'prompt' since it returns an mcp.Prompt, not a tool. This naming is inconsistent and misleading.
func IssueInvestigationWorkflowPrompt(t translations.TranslationHelperFunc) (tool mcp.Prompt, handler server.PromptHandlerFunc) {
pkg/github/workflow_prompts.go:140
- The return parameter name 'tool' should be 'prompt' since it returns an mcp.Prompt, not a tool. This naming is inconsistent and misleading.
func IssueToFixWorkflowPrompt(t translations.TranslationHelperFunc) (tool mcp.Prompt, handler server.PromptHandlerFunc) {
Co-authored-by: Copilot <[email protected]>
…ub-mcp-server into multi-tool-workflows
* initial workflows * fixing tabs * remove unused SecurityAlertWorkflowPrompt and RepositorySetupWorkflowPrompt * add workflow prompt for creating issue and assigning to copilot * Update pkg/github/workflow_prompts.go Co-authored-by: Copilot <[email protected]> * remove notif triage * remove code inv workflow tool * rm another --------- Co-authored-by: Copilot <[email protected]>
Add CachedInventory to build tool/resource/prompt definitions once at startup rather than per-request. This is particularly useful for the remote server pattern where a new server instance is created per request. Key features: - InitInventoryCache(t) initializes the cache once at startup - CachedInventoryBuilder() returns a builder with pre-cached definitions - Per-request configuration (read-only, toolsets, feature flags) still works - Thread-safe via sync.Once - Backward compatible: NewInventory(t) still works without caching This addresses the performance concern raised in go-sdk PR #685 at a higher level by caching the entire []ServerTool slice rather than individual schemas. Related: modelcontextprotocol/go-sdk#685
Add CachedInventory to build tool/resource/prompt definitions once at startup rather than per-request. This is particularly useful for the remote server pattern where a new server instance is created per request. Key features: - InitInventoryCache(t) initializes the cache once at startup - InitInventoryCacheWithExtras(t, tools, resources, prompts) allows injecting additional items (e.g., remote-only Copilot tools) - CachedInventoryBuilder() returns a builder with pre-cached definitions - Per-request configuration (read-only, toolsets, feature flags) still works - Thread-safe via sync.Once - Backward compatible: NewInventory(t) still works without caching This addresses the performance concern raised in go-sdk PR #685 at a higher level by caching the entire []ServerTool slice rather than individual schemas. Related: modelcontextprotocol/go-sdk#685
Closes: https://github.com/github/copilot-agent-services/issues/322