Description
When importing a .gadget blueprint whose bindings are MCP gatekeeper bindings with distinct resourceUrls, the binding-assignment UI preselects an existing MCP account of the same vendor type without matching the binding's resourceUrl — and the outer assignment screen displays the blueprint's suggested URL as if it were the selection, so the mismatch is invisible until Create fails (or, worse, doesn't).
Observed on our self-hosted deployment (starter pin 3d211477, cloudflare-os 6478a144); still reproduces for us as of 2026-08-30, and the picker components look unchanged on current main.
Steps observed
Reproduction A — two same-type bindings, wrong one preselected:
- Blueprint with two MCP bindings:
LINEAR (resourceUrl: https://mcp.linear.app/mcp) and GITLAB (resourceUrl: https://gitlab.com/api/v4/mcp). Workspace has both accounts connected.
- Import the blueprint. The outer screen showed the LINEAR row as "Ready — Using: https://mcp.linear.app/mcp", but the actual preselection was the GitLab account.
- Create failed with:
This connection is for https://gitlab.com/api/v4/mcp, not https://mcp.linear.app/mcp.
- Workaround: open Change on every MCP binding and pick the account explicitly.
Reproduction B — no matching account exists at all:
- Blueprint binding
BRAND_VOICE with resourceUrl: https://bv.inspekter.app/mcp; no account for that endpoint exists in the workspace.
- The outer screen presents the binding as correctly assigned (showing the blueprint's suggested URL).
- Opening the binding's configuration dialog shows an unrelated same-type account (mcp.linear.app) already selected with a checkmark, with that account's 62 tools listed below.
So this doesn't look like a fuzzy match gone wrong: the picker appears to default to an arbitrary existing account of the vendor regardless of resourceUrl, and the summary renders the blueprint's suggestion rather than the actual selection.
Expected behavior
- Preselect only an account whose endpoint matches the binding's
resourceUrl (respecting typeUrlPattern); otherwise preselect nothing and prompt to connect.
- The outer assignment screen should render the actual selected account, not the blueprint's suggested URL.
Impact
Silent cross-wiring of connections. With the "Create fails" guard (repro A) it costs a confusing error; if any code path saves without that guard (repro B's dialog offers "Save connection"), a gadget ends up calling a completely different MCP server than its blueprint declared — with whatever tools and approval tiering that account happens to have.
Description
When importing a
.gadgetblueprint whose bindings are MCP gatekeeper bindings with distinctresourceUrls, the binding-assignment UI preselects an existing MCP account of the same vendor type without matching the binding'sresourceUrl— and the outer assignment screen displays the blueprint's suggested URL as if it were the selection, so the mismatch is invisible until Create fails (or, worse, doesn't).Observed on our self-hosted deployment (starter pin
3d211477, cloudflare-os6478a144); still reproduces for us as of 2026-08-30, and the picker components look unchanged on currentmain.Steps observed
Reproduction A — two same-type bindings, wrong one preselected:
LINEAR(resourceUrl: https://mcp.linear.app/mcp) andGITLAB(resourceUrl: https://gitlab.com/api/v4/mcp). Workspace has both accounts connected.This connection is for https://gitlab.com/api/v4/mcp, not https://mcp.linear.app/mcp.Reproduction B — no matching account exists at all:
BRAND_VOICEwithresourceUrl: https://bv.inspekter.app/mcp; no account for that endpoint exists in the workspace.So this doesn't look like a fuzzy match gone wrong: the picker appears to default to an arbitrary existing account of the vendor regardless of
resourceUrl, and the summary renders the blueprint's suggestion rather than the actual selection.Expected behavior
resourceUrl(respectingtypeUrlPattern); otherwise preselect nothing and prompt to connect.Impact
Silent cross-wiring of connections. With the "Create fails" guard (repro A) it costs a confusing error; if any code path saves without that guard (repro B's dialog offers "Save connection"), a gadget ends up calling a completely different MCP server than its blueprint declared — with whatever tools and approval tiering that account happens to have.