Rebase the mcp/registry dependency to v1.3.3 #297
Conversation
🔧 MCP Server Tool List UpdatesThe tool lists for modified MCP server specs have been automatically updated using Summary
This comment is automatically generated and will be updated as the workflow progresses. |
rdimitrov
force-pushed
the
rebase-registry-dep
branch
from
1cf745f to
03298de
Compare
go.mod
Outdated
| module github.com/stacklok/toolhive-registry | ||
|
|
||
| go 1.24.5 | ||
| go 1.25 |
There was a problem hiding this comment.
Does ToolHive import this at all? If so, we're gonna have some trouble. We're on 1.24 in toolhive because that's what UBI currently supports.
There was a problem hiding this comment.
yeah, I was unsure about this too but it comes from registry which is unfortunately on 1.25, would it be possible to bump UBI?
There was a problem hiding this comment.
It is not. The version wil bump in a month or so
There was a problem hiding this comment.
ah, that's a bummer. Let's figure out something then
There was a problem hiding this comment.
made it to work with 1.24.6 👍
| pulls: 8029 | ||
| last_updated: "2025-10-21T02:31:33Z" | ||
| repository_url: https://github.com/StacklokLabs/ocireg-mcp | ||
| target_port: 8080 |
There was a problem hiding this comment.
the oci registry MCP supports the MCP_PORT environment variable, so the target port is not needed. The same is true for most other Stacklok MCP servers.
There was a problem hiding this comment.
This comes from the upstream format where we have to set an explicit value if the server is using an HTTP-based transport type. I guess we can still overwrite it in the runtime by passing the MCP_PORT env var, right?
There was a problem hiding this comment.
we could. But that's not how toolhive works. If you dont specify a port, toolhive will assign one. If you do specify it, toolhive will take the one that's been specified. So, ultimately this kind of setup where containers have the same port will result in conflicts and not being able to run MCP servers of HTTP or SSE transports if they have the same port.
There was a problem hiding this comment.
wait, I might have gotten this wrong. My understanding is target_port is the port that the server is implemented to listen on (inside the container)? From there on if that port is free on the host, toolhive may use it, otherwise it will choose a random one, right?
There was a problem hiding this comment.
And what happens if that port is not available?
There was a problem hiding this comment.
I agree we should always have a clear specification of the default target port.
In case an env variable can override the default, shouldn't we identify it with a specific attribute?
- name: MCP_PORT
overrideMcpPort: true
description: HTTP server port (HTTP mode only)
required: false
default: "8080"
BTW: I can't see this MCP_PORT variable in the oci-registry server (only in the GH repo)
Signed-off-by: Radoslav Dimitrov <[email protected]>
Signed-off-by: Radoslav Dimitrov <[email protected]>
Signed-off-by: Radoslav Dimitrov <[email protected]>
Signed-off-by: Radoslav Dimitrov <[email protected]>
…:\n- sqlite\n\nAutomatically updated using 'thv mcp list' command.\n\nCo-authored-by: rdimitrov <[email protected]>
Signed-off-by: Radoslav Dimitrov <[email protected]>
Signed-off-by: Radoslav Dimitrov <[email protected]>
rdimitrov
force-pushed
the
rebase-registry-dep
branch
from
ceb8d9c to
7059b7f
Compare
Signed-off-by: Radoslav Dimitrov <[email protected]>
There was a problem hiding this comment.
shouldn't we have separate source files for upstream-to-toolhive and viceversa, to make the scope clearer?
There was a problem hiding this comment.
Thanks! I'll split it right away 👍
4 participants
The following PR: