Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat: add MCP tools for ChatGPT#19102

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
hugodutka merged 11 commits intomainfromhugodutka/chatgpt-mcp
Aug 4, 2025
Merged

feat: add MCP tools for ChatGPT#19102

hugodutka merged 11 commits intomainfromhugodutka/chatgpt-mcp
Aug 4, 2025

Conversation

hugodutka
Copy link
Contributor

@hugodutkahugodutka commentedJul 30, 2025
edited
Loading

Addressescoder/internal#772.

Adds a new/api/experimental/mcp/chatgpt endpoint which exposes newfetch andsearch tools compatible with ChatGPT, as described in theChatGPT docs. These tools are exposed in isolation because in my usage I found that ChatGPT refuses to connect to Coder if it sees additional MCP tools.

Screenshot 2025-07-30 at 16 36 56

@hugodutkahugodutkaforce-pushed thehugodutka/chatgpt-mcp branch 2 times, most recently fromccc3a6a to3e42d7aCompareJuly 30, 2025 14:51
@hugodutkahugodutka marked this pull request as ready for reviewJuly 30, 2025 15:03
Copy link
Member

@ThomasK33ThomasK33 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Looking good, just a few small code organization tweaks.
I'd prefer to add a new Register function to the server struct so that we can handle this one edge case instead of refactoring the whole thing.

For anyone looking at this PR: ChatGPT connectors are 'questionable' (ask for my opinion in Slack 😉) and adding a dedicated endpoint makes sense for the sake of dogfood and sanity.

// RegisterTools registersall availableMCP tools with the server
func (s*Server)RegisterTools(client*codersdk.Client)error {
// RegisterTools registers MCP tools with the server
func (s*Server)RegisterTools(client*codersdk.Client,tools []toolsdk.GenericTool)error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Could we leave the function as it was and add a new function calledRegisterChatGPTTools instead?

This would benefit us by allowing us to add exceptions for ChatGPT more easily on the server structure, and keeping the existing MCP endpoint and function calls as they are/will be.

(Also, we can then write a unit test and assert that a ChatGPT MCP server only has those two tools that we expect)

hugodutka reacted with thumbs up emoji
}
}()

ctx,cancel:=context.WithTimeout(context.Background(),testutil.WaitLong)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Suggested change
ctx,cancel:=context.WithTimeout(context.Background(),testutil.WaitLong)
ctx,cancel:=context.WithTimeout(t.Context(),testutil.WaitLong)

hugodutka reacted with thumbs up emoji

// mcpHTTPHandler creates the MCP HTTP transport handler
func (api*API)mcpHTTPHandler() http.Handler {
func (api*API)mcpHTTPHandler(tools []toolsdk.GenericTool) http.Handler {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I think we could simplify this a bit by making it a boolean calledisChatGPT bool, then calling the appropriate Register function (either.RegisterTools() or.RegisterChatGPTTools()).

This also makes the handler less complex.

hugodutka reacted with thumbs up emoji
Comment on lines 17 to 22
funcgetServerURL(depsDeps)string {
serverURLCopy:=*deps.coderClient.URL
serverURLCopy.Path=""
serverURLCopy.RawQuery=""
returnserverURLCopy.String()
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We may want to add a new function toDeps.
Then we could justdeps.ServerURL() to get it.

hugodutka reacted with thumbs up emoji

funcsearchTemplates(ctx context.Context,depsDeps) ([]SearchResultItem,error) {
serverURL:=getServerURL(deps)
templates,err:=deps.coderClient.Templates(ctx, codersdk.TemplateFilter{})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Can we use the SearchQuery field to parameterize this?

hugodutka reacted with thumbs up emoji
Copy link
Member

@ThomasK33ThomasK33 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I like the approach with the query param more than adding a new endpoint 👍

We might want to turn it into asource query parameter since that would enable us to composite multiple toolsets into client-specific ones, without "leaking" that abstraction.

typeMCPToolsetstring

const (
MCPToolsetStandardMCPToolset="standard"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We might defineStandard one to be the default empty value, then we don't need to do additional checks later on.

Suggested change
MCPToolsetStandardMCPToolset="standard"
MCPToolsetStandardMCPToolset=""

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Neat trick, but it feels unintuitive - especially if we add debug logging with toolset names later. I'd be surprised to see this pattern as a reader.

)

// mcpHTTPHandler creates the MCP HTTP transport handler
// It supports a "toolset" query parameter to select the set of tools to register.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Do we want to expose toolsets specifically, or do we want to add a simple?source=chatgpt and then internally map to the corresponding toolsets?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I conceptually prefer toolsets over sources. It feels more appropriate for the client to choose which tools it wants to access, rather than having the server adapt to the client.

ThomasK33 reacted with thumbs up emoji
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Makes sense.

Would it be possible to specify multiple toolsets then?

Say we split the param on, and then composite them into a new one. Then one could have a?toolset=chatgpt,workspaces only to get the chatgpt and workspace-related tools.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

That could definitely be a later-stage extension.

@hugodutkahugodutka merged commit79cd80e intomainAug 4, 2025
26 checks passed
@hugodutkahugodutka deleted the hugodutka/chatgpt-mcp branchAugust 4, 2025 12:11
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsAug 4, 2025
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@ThomasK33ThomasK33ThomasK33 approved these changes

Assignees

@hugodutkahugodutka

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@hugodutka@ThomasK33

[8]ページ先頭

©2009-2025 Movatter.jp