Register managed-config MCP servers on launch - #304
Merged
Conversation
A workspace's managed config lists MCP servers, but nothing on the launch path
ever registered them with the agent — resolve_state handles models/provider but
has no MCP handling, and the servers were only shown in the summary as
"(pending)". So a workspace-published MCP server never reached the agent's /mcp
list.
Register them on launch: reconstruct each server's URL from its {name, type}
and apply it for the launching tool via the same path `configure mcp` uses.
Supports the types whose URL is recoverable from name+type alone — sql,
external, and mcp-service (the stored dash-form name un-dashes to the UC dotted
form for the URL). Types that need an id/host the manifest doesn't carry
(genie-space, app, vector-search, uc-functions) are skipped with a warning
pointing at `ucode configure mcp`.
Registered servers are persisted under managed_mcp_servers so the next launch
diffs against them (a server the admin removes gets unregistered), and
revert_mcp_configs now clears them too.
Co-authored-by: Isaac
Extends managed-config MCP registration beyond sql/external/mcp-service to genie-space, vector-search, and uc-functions — every type whose URL is workspace-relative (only `app`, which needs an off-workspace host, remains). The fix is in what the admin serializer stores. It previously published the local *display* name (a lossy slug like `databricks-functions-dev-cat-fixture`, where underscores became hyphens and the catalog/schema boundary was gone), so the launch path couldn't rebuild the URL. Now it derives the identifier the ai-gateway `McpServer.name` field is meant to hold from the resolved URL: a space id for genie, `<catalog>.<schema>` for vector-search/uc-functions, the dash-form UC name for mcp-service, a connection name for external. The launch path reconstructs `(entry_name, url)` from that, registering under the same dot-free name the interactive path uses so a managed and local copy don't double-register. `managed_mcp_server_url` became `managed_mcp_server_entry` (returns name + url), and the serializer's `_mcp_type_for_url` became `_mcp_server_from_url` (returns name + type). Apps are skipped with a warning on both sides. Co-authored-by: Isaac
A managed config can't carry a Databricks app (its host isn't reconstructable
from the workspace), so the serializer drops apps — but the shared picker still
offered them, letting an admin pick an app, see "added", and have it silently
disappear from the published config.
`ucode setup` now passes exclude_sources={"apps"} to the picker, which drops the
"Databricks apps" search source and hides any already-registered app server, so
an admin only sees servers a managed config can actually carry. The developer
`ucode configure mcp` path is unchanged — apps still work there.
Co-authored-by: Isaac
tt-le
approved these changes
Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A workspace's managed config lists MCP servers, but nothing on the launch path ever registered them with
the agent —
resolve_statehandles models/provider but had no MCP handling, and the servers were onlyshown in the summary as "(pending)". So a workspace-published MCP server never reached the agent's
/mcplist.
This registers them on launch, reconstructing each server's URL from its
{name, type}and applying itfor the launching tool via the same path
configure mcpuses.Supported types (every one whose URL is workspace-relative):
sql,external,mcp-servicegenie-space(stores the space id),vector-search/uc-functions(store<catalog>.<schema>)The fix for genie/vector-search/uc-functions was in what the admin serializer stores: it used to publish
the local display slug (e.g.
databricks-functions-dev-cat-fixture— underscores flattened to hyphens,catalog/schema boundary lost), which the launch path couldn't reverse. Now it stores the identifier the
ai-gateway
McpServer.namefield is documented to hold per type. No server-side change needed — theproto already models this.
Apps are the one type a managed config can't carry (the host is off-workspace, not reconstructable
from the workspace + an id). They're skipped by the serializer, and
ucode setup's picker now hides the"Databricks apps" source so an admin never picks one that gets silently dropped. The developer
ucode configure mcppath is unchanged — apps still work there.Registered servers are persisted under
managed_mcp_serversso the next launch diffs against them (aserver the admin removes gets unregistered), and
revert_mcp_configsclears them too.Verified end-to-end against a live workspace: all six reconstructable types register with correct proxy
URLs, including the
dev_elaine_wang_...uc-functions case that was broken before.Co-authored-by: Isaac