docs: explain saved MCP servers in web chat - #137
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![mogplex[bot]](https://avatars.githubusercontent.com/in/3107927?s=60&v=4){kind=small}
There was a problem hiding this comment.
Mogplex PR Review
Status: Attention needed
Docs-only PR adding a "Use a saved server in web chat" subsection to content/docs/configure-and-extend/connections-and-mcp.mdx. The prose itself is clear and matches the stated intent, and there are no security or correctness risks. Three non-blocking issues worth fixing before merge: (1) the new H3 is inserted mid-section, so the pre-existing paragraphs about personal-account ownership and legacy Settings links are now orphaned under the web-chat heading; (2) the canonical "Where connection tools load" table further down the same page still implies MCP tooling only reaches Claude Code sandbox runs and the CLI, contradicting the new claim that saved servers supply tools to web chat and Control; (3) content/docs/web/settings.mdx still describes the MCP Servers tab as "for CLI sync" / "for CLI server definitions" in two places, which now contradicts this page. Smaller notes on the unanswered scope/cap/timeout questions and vague phrasing. Also confirm merge ordering — the PR body says this depends on an unreleased app change.
Warnings
- New H3 orphans the section's closing paragraphs (content/docs/configure-and-extend/connections-and-mcp.mdx:L22)
The### Use a saved server in web chatheading is inserted before the paragraphs that previously closed## Open Connections. As of this diff, "Connections belong to your personal account. Shared team connections are not available yet..." (line 38) and the "Old Settings links with?tab=connections..." paragraph now render inside the web-chat subsection, even though they describe the Connections page generally, not saved-server web-chat behavior.
Suggestion: move the new H3 block below those two paragraphs so it closes the section, or promote it to its own ## section placed after ## Open Connections.
- "Where connection tools load" table contradicts the new claim (content/docs/configure-and-extend/connections-and-mcp.mdx)
Further down the same page, the## Where connection tools loadtable lists "Claude Code sandbox runs, Mogplex CLI | MCP connections, synced as MCP config" and gives Control/workspace chat only "every enabled connection in scope." A reader who consults that table (the canonical reference on this page) will conclude saved MCP servers still do not reach web chat, which is exactly what this PR says changed.
I may be missing an intentional distinction between Connections-of-type-MCP-Server and the saved servers in the MCP Servers tab — if so, that distinction is not stated anywhere and is the main thing worth spelling out. Suggestion: add a row or footnote to that table for saved MCP servers, and cross-link it from the new subsection.
-
settings.mdx still describes the MCP Servers tab as CLI-only (content/docs/web/settings.mdx)
Two statements incontent/docs/web/settings.mdxnow contradict this PR: -
"Open Connections → MCP Servers to manage server definitions for CLI sync."
-
"Use Integrations for services and MCP Servers for CLI server definitions."
This PR changed the equivalent line in connections-and-mcp.mdx to "manages saved servers for web chat and the Mogplex CLI" but left the parallel text here stale. Suggestion: update both lines in the same PR so the two pages ship consistent guidance with the app release.
Suggestions
- Unanswered scope, cap, and timeout questions for saved servers (content/docs/configure-and-extend/connections-and-mcp.mdx:L31)
The new subsection says saved servers now feed chat but does not say whether the existing operating rules apply to them: the five-enabled-MCP cap per resolved scope (## MCP limits), global/project/exclusion scope resolution, and Control's eight-second remote-MCP wait. These are the first questions a reader hitting a missing tool will ask. One sentence plus links to those sections would close the gap.
Also, "Team capability checks still apply" (line 32) and "Other chat surfaces withhold them" (line 33) are vague — naming the check and the surfaces (workspace chat, Slack agent, native-harness runs) would make them actionable.
- Minor: stale frontmatter description and approval-mode terminology (content/docs/configure-and-extend/connections-and-mcp.mdx:L3)
- Line 3: the page description still says "sync saved server definitions" only; consider mentioning that saved servers also supply chat tools.
- Line 33: the new text uses the
promptapproval mode in Extra JSON, while## Asking before a connection's tools runuses the UI labels "Ask before running tools" /asks first. If these are two different mechanisms, say so briefly; if they are the same, use one vocabulary. - PR hygiene: the body notes this depends on an unreleased app change. Worth confirming the merge is gated on that release so the docs do not describe behavior users cannot yet observe.
There was a problem hiding this comment.
Mogplex PR Review
Status: Attention needed
Docs-only PR (2 MDX files) documenting that saved HTTP MCP servers now supply tools to web chat and Control. No code, so no security or correctness risk. The new content is well written and mostly consistent with the surrounding doc, but three points need discussion before merge: (1) it introduces "web chat" as a surface name alongside the doc's established "workspace chat" without defining the distinction or the equivalence; (2) the canonical "Where connection tools load" table is not updated, so saved-server coverage exists only as prose underneath and Claude Code / Codex sandbox-run behavior is left unstated; (3) the claim that "the team's connections.create capability still controls access to these tools" appears to contradict two nearby statements that saved connections are personal and that shared team connections do not exist yet. Also worth noting: the PR body says this depends on an unreleased app change, so merge ordering matters and the docs describe behavior that is not yet live. Evidence: content/docs/configure-and-extend/connections-and-mcp.mdx L31-49 (new section), L165-168 and L206-207 (updated sections), L22-24 and L153-160 (pre-existing statements the new text interacts with); content/docs/web/settings.mdx L79, L190.
6 findings were added inline.
Suggestions
- Scope-and-overrides guide is now incomplete for MCP tool surface (content/docs/web/guides/connection-scope-and-overrides.mdx)
This file is not in the PR, but the new statement at connections-and-mcp.mdx L166 ("Integration scope exclusions do not apply to this separate catalog") undercuts its central advice. That guide tells readers the MCP limit is enforced against "the resolved runnable set for that repo" and that "excluding a noisy global MCP can be the difference between a clean tool surface and an overstuffed one" — no longer the whole picture now that a second, exclusion-immune MCP source feeds the same runs. Not a blocker for this PR, but a cross-link or one-sentence caveat there would keep the two pages from drifting.
There was a problem hiding this comment.
Mogplex PR Review
Status: Attention needed
Documentation-only change across two MDX files explaining that saved HTTP MCP servers now supply tools to web chat and Control, not just CLI sync. No code, no security surface, no build impact. The new "Use a saved server in web chat" section is well written and the terminology updates in web/settings.mdx are consistent with it.
No critical or blocking issues. I could not verify the described runtime behavior (public-URL requirement, eight-second budget, per-tool prompt handling, uncapped saved-server catalog) because the app change lives in another repo — the PR body itself notes this depends on an unreleased app change, so these claims rest on the author's knowledge.
Four non-blocking documentation-consistency gaps: the unchanged Troubleshooting table and "Where connection tools load" table were not updated to cover the new saved-server path, the approval-semantics clarification sits far from the section it corrects, and one sentence about team capability appears to conflict with the page's statement that connections are personal. Recommend addressing the table gaps before merge since those are the sections readers land on when debugging.
2 findings were added inline.
Suggestions
- Troubleshooting table still assumes the repo-scoped resolution model (content/docs/configure-and-extend/connections-and-mcp.mdx)
The new prose states that saved servers "belong to the user and apply across repos" and that "Integration scope exclusions do not apply to this separate catalog." The unchanged Troubleshooting table was not updated to match: the first row still says "Tool missing in a hosted run → Confirm the connection is enabled and included in the repo's resolved set," and the second row points at project exclusions and the connection cap.
For a missing saved-server tool, none of that guidance applies — there is no resolved set, no exclusion, and no cap. A user debugging the new path will be sent down a dead end from the section specifically designed for debugging.
Suggestion: add a row such as "Saved MCP Servers tool missing in web chat → Confirm the server is Enabled, uses Streamable HTTP with a public URL, and is not excluded by disabled_tools; a server that misses the eight-second startup budget is skipped for that turn."
- "Where connection tools load" table leaves saved-server behavior undefined for two surfaces (content/docs/configure-and-extend/connections-and-mcp.mdx)
The added paragraph covers Control, workspace chat, the Slack agent, and native-harness runs, but the table directly above it has two more rows: "Claude Code sandbox runs, Mogplex CLI" and "Codex sandbox runs." The new prose says nothing about whether saved servers reach Claude Code sandbox runs, and the CLI sync path is documented separately further down.
Since the table is the canonical at-a-glance reference on this page, leaving two of its four rows unaddressed for the new catalog invites the wrong inference either way. Suggestion: either add a saved-servers column to the table, or extend the paragraph with an explicit sentence on sandbox runs (for example, "Claude Code sandbox runs receive Integration MCP config only; saved servers reach the Mogplex CLI through catalog sync") — whichever matches actual behavior.
There was a problem hiding this comment.
Mogplex PR Review
Status: Attention needed
Docs-only PR (3 files) documenting that saved MCP servers in the MCP Servers catalog now supply tools to web chat and Control. The structure is good: the new "Use a saved server in web chat" section, the split "Where connection tools load" table, the Integrations-only scoping of the approvals section, and the cross-links from connection-scope-and-overrides.mdx and settings.mdx are consistent with each other, and the anchor /configure-and-extend/connections-and-mcp#use-a-saved-server-in-web-chat resolves to the new heading. No factual contradictions found inside the page (HTTP-public-URL vs stdio CLI-only, prompt-mode Control-only, eight-second startup budget, and the troubleshooting rows all line up). Two gaps keep this from being approve-ready as written: (1) the page makes saved-server permissions depend on "Extra JSON" keys (enabled_tools, disabled_tools, per-tool restrictions, an explicit prompt approval mode) that are documented nowhere in the site — reference/api.mdx's MCP server payload only shows id/name/transport/command/args/env/url/http_headers, and cli/concepts/approvals.mdx has no prompt mode — so a reader told to "check saved tool restrictions" has no schema to check against; (2) the sentence introducing the team-scope connections.create capability is both undefined elsewhere in the docs and semantically confusing next to "Servers remain personal". Everything else is a soft suggestion. Also note the PR itself says this depends on Mogplex/mogplex#522 and must merge after that app release — the page has no in-page signal (Callout/version note), so an early merge would ship inaccurate behavior docs.
Warnings
- Extra JSON permission keys are referenced three times but never documented anywhere (content/docs/configure-and-extend/connections-and-mcp.mdx)
In content/docs/configure-and-extend/connections-and-mcp.mdx the new section states that "Savedenabled_tools,disabled_tools, and per-tool restrictions in Extra JSON also apply to chat" and that "Tools with an explicitpromptapproval mode require Control". The "Asking before a connection's tools run" section then redirects readers to "the [Extra JSON permissions described above]", and the troubleshooting table tells them to "Check saved tool restrictions" and to "Use Control for tools with an explicitpromptapproval mode".
Nothing in the docs shows the shape of that JSON. content/docs/reference/api.mdx documents the MCP server payload as only id/name/transport/command/args/env/url/http_headers, and content/docs/cli/concepts/approvals.mdx documents allow/ask/deny modes with no prompt mode. A reader who follows the pointer has no key names, nesting, or per-tool syntax to act on.
Suggestion: add a short fenced JSON example under the new section showing a real Extra JSON blob with enabled_tools, disabled_tools, and the per-tool approval mode set to prompt, or link to wherever that schema is authoritative and add it to reference/api.mdx alongside the MCP server config type.
connections.createteam capability is undefined and reads contradictory (content/docs/configure-and-extend/connections-and-mcp.mdx)
The line "Servers remain personal. When a turn runs in team scope, the caller also needs the team'sconnections.createcapability." introduces a capability identifier that appears nowhere else in the docs (not in web/spaces.mdx, web/settings.mdx, or the connection scope guide), and the two sentences pull against each other: if the catalog is personal, requiring a create capability to use tools during a turn is surprising enough that readers will assume it is a typo for a read/use capability.
Was the create capability intentional (i.e. the app reuses that gate), or should this be a different capability? Either way, phrase it in terms readers can verify — which team roles hold it and where it is granted — rather than exposing a bare internal identifier. If the identifier must stay, add a one-clause explanation such as "which owners and admins have by default".
Suggestions
- Header secrecy claim sits in tension with the page's own security notes (content/docs/configure-and-extend/connections-and-mcp.mdx)
"Saved secret headers stay hidden in the browser. Mogplex sends them to the configured MCP server when it connects." is accurate for the UI, but the Security notes further down warn that MCP server config responses "can include decrypted headers, env vars, or OAuth access tokens", and reference/api.mdx repeats that warning for GET /mcp/servers. A reader scanning only the new section can come away believing saved headers are never retrievable. Consider appending "(the catalog API still returns them — see Security notes)". - "No server-count cap" undercuts the stated rationale for the Integrations cap (content/docs/configure-and-extend/connections-and-mcp.mdx)
The MCP limits section now says the Integrations cap is five per resolved scope while "The MCP Servers catalog has no server-count cap", yet the very next paragraph explains the cap exists because "an oversized or noisy tool surface" harms runs. Since saved servers now feed the same web chat turns, the same failure mode applies without a guardrail. A sentence recommending that users keep the saved catalog small (and disable unused servers) would keep the advice coherent. - Frontmatter description drops the Mogplex-MCP-endpoint distinction that the page still teaches (content/docs/configure-and-extend/connections-and-mcp.mdx)
The description changed to "Configure external tools, use saved MCP servers in web chat and the CLI, and understand connection scope and permissions." The "Direction matters" section — the page's main disambiguation between external connections and the Mogplex MCP endpoint — is unchanged and is a common search intent. Consider keeping a short clause about distinguishing the Mogplex MCP endpoint so search and card previews still surface it. - New prose is unwrapped while the surrounding file wraps at ~80 columns (content/docs/configure-and-extend/connections-and-mcp.mdx)
The added paragraphs in the new section and in "Where connection tools load" are single long lines, whereas the pre-existing body text in this file wraps near 80 characters. Mixed wrapping makes future line-level diffs noisier. If the repo has no enforced proseWrap setting (no .prettierrc at root), matching the file's existing wrap width is the safer default. - No in-page signal that this documents unreleased behavior (content/docs/configure-and-extend/connections-and-mcp.mdx)
The PR description says this depends on Mogplex/mogplex#522 and should merge only after that app release, but the page itself has no Callout or version note. If merge ordering slips, readers get behavior docs that do not match production. Consider a temporary Callout, or rely on a do-not-merge label until the app release lands.
There was a problem hiding this comment.
Mogplex PR Review
Status: Attention needed
Docs-only PR documenting that saved HTTP MCP servers now supply tools to web chat and Control, not just CLI sync. The structure is good: the new "Use a saved server in web chat" section, the split Integrations/Saved-MCP-Servers table, and the "this section describes Integrations" disambiguators all land well, and the cross-links (#use-a-saved-server-in-web-chat) resolve correctly. No security or factual errors found that I can verify from the repo.
Four things need a pass before merge, all wording/completeness rather than structural:
- An apparent contradiction about who can use a saved server in team scope (L44) versus the existing "shared team connections are not available yet" statement earlier on the page.
- "web chat" is defined narrowly at L33 (workspace chat + Control) but later used loosely to include the Slack agent and native-harness runs, which changes what a reader thinks is withheld.
- The page never says what a server-level
default_tools_approval_mode: "prompt"does. Since the whole approval story hinges on "explicit prompt approval mode," this gap decides whether a user's tools silently run or silently disappear. - In connection-scope-and-overrides.mdx the new paragraphs were inserted between "Connections in Mogplex..." and "They resolve at two levels:", so the pronoun now appears to refer to the MCP Servers catalog — the exact opposite of what the inserted sentence says.
I could not verify the runtime claims (eight-second Control deadline, six-second discovery budget, no server-count cap, auto/approve/deny/prompt mode names) against app source, since this is the docs repo; those should be confirmed against Mogplex/mogplex#522. Also note the stated dependency on that PR — these pages describe behavior that is not live yet, so merge ordering matters.
5 findings were added inline.
Suggestions
- Startup deadlines are documented only for Control, but troubleshooting points all web chat users at them (content/docs/configure-and-extend/connections-and-mcp.mdx)
Under "Where connection tools load," the timing paragraph is scoped to Control: "Control waits up to eight seconds for remote MCP servers... Saved-server discovery uses a six-second startup budget." The troubleshooting row "Saved MCP tool missing in web chat" then tells users to "Check ... the startup deadline" — but the page never says whether workspace chat, the Slack agent, or native-harness runs share the same eight-second window.
Adding "the same deadline applies to workspace chat, the Slack agent, and native-harness runs" (or the correct per-surface values) would make the troubleshooting row actionable. Separately, these numbers plus "The MCP Servers catalog has no server-count cap" are runtime claims I cannot verify from this repo — worth confirming against Mogplex/mogplex#522, since an uncapped catalog interacting with a fixed startup budget is exactly where a user would hit silent tool drop-out.
- Security notes not revisited now that saved servers reach hosted chat (content/docs/configure-and-extend/connections-and-mcp.mdx)
The "Security notes" list is unchanged and still framed around the CLI-sync catalog (treat/api/v1/mogplex/mcp/serversoutput like.env, do not paste it in logs). With this PR, saved HTTP servers become an active tool surface in hosted chat and Control, and L38 notes that Mogplex sends saved secret headers to the configured server.
Not a blocker, but a bullet mirroring the existing "exclude global MCPs from repos where the tool surface would be unsafe" guidance — applied to saved servers, which have no scope exclusions per the "Where connection tools load" note — would keep the section aligned with the new behavior.
There was a problem hiding this comment.
Mogplex PR Review
Status: Attention needed
Docs-only PR that documents saved MCP servers being available to web chat/Control in addition to CLI sync. The new "Use a saved server in web chat" section, the split Integrations vs. Saved MCP Servers load table, the qualified "Asking before…" and "MCP limits" sections, and the updated cross-links in settings.mdx and connection-scope-and-overrides.mdx are internally consistent, and the in-page/cross-page anchor (#use-a-saved-server-in-web-chat) matches the new heading. No security or correctness blockers. Remaining items are accuracy/consistency polish: one role/ownership sentence that reads as contradicting the page's earlier "connections belong to your personal account" statement, a "Scope resolution" section that is now the only unqualified section left, a stale section-index card description for this same page, and several hard behavioral claims (8s/6s deadlines, approve synonym, "no server-count cap") that only the dependent app PR can confirm.
Warnings
- Team-scope/role sentence conflicts with the page's earlier ownership statement (content/docs/configure-and-extend/connections-and-mcp.mdx)
In the new section: "Servers stay private to the account that created them. In team scope, owners, admins, and developers can use their own saved servers. Viewers cannot use connection tools."
Earlier on the same page the reader was told "Connections belong to your personal account. Shared team connections are not available yet. In a team scope, select Open personal connections to manage your own services." If every saved server is private to its creator, it is unclear why the team role matters at all, and "Viewers cannot use connection tools" is a broad claim that extends beyond saved servers to Integrations without being documented anywhere else on the page.
Suggestion: state the rule the app actually enforces, e.g. "Saved servers are never shared. In a team scope you still use your own servers, and members with the Viewer role cannot run saved-server tools." Please confirm the exact role gate (and whether it truly applies to Integrations too) against Mogplex/mogplex#522 before merge.
Suggestions
- "Scope resolution" is now the only section not qualified to Integrations (content/docs/configure-and-extend/connections-and-mcp.mdx)
The PR carefully scopes "Asking before a connection's tools run" ("This section describes Integrations") and "MCP limits" ("from Integrations … The MCP Servers catalog has no server-count cap"), and states in the load table that "Integration scope exclusions do not apply to this separate catalog." The "Scope resolution" section still opens with the unqualified "Connections can be global or project-scoped", which now contradicts the new catalog behavior for a reader skimming headings.
Suggestion: add one line mirroring the others, e.g. "This section describes Integrations. Saved MCP Servers apply across repos and ignore global/project scope and exclusions."
-
Section-index card for this page still describes the catalog as CLI-only (content/docs/configure-and-extend/index.mdx)
content/docs/configure-and-extend/index.mdxhas: description="Configure REST and MCP tools, understand scope resolution, and sync cloud MCP servers into the CLI." for the External Connections card. The PR updated the page front-matter and the two settings.mdx mentions but left this card, so the section index still frames saved MCP servers as CLI sync only. Consider aligning it with the new front-matter description. -
Hard behavioral numbers and value names to confirm against the dependent app PR (content/docs/configure-and-extend/connections-and-mcp.mdx)
These claims are not verifiable from this repo and will silently rot if the app changes: -
"Control waits up to eight seconds … Saved-server discovery uses a six-second startup budget."
-
"
autoandapproveboth allow automatic calls" (two accepted synonyms) and "Per-tooldenyexcludes a tool". -
"The MCP Servers catalog has no server-count cap."
Worth a final pass against Mogplex/mogplex#522 before merging, since the PR description already gates this on that app release.
- Example JSON walkthrough omits the non-Control outcome, and the withhold sentence is duplicated (content/docs/configure-and-extend/connections-and-mcp.mdx)
The example says it "allowssearchandpublish, blocksdelete, and asks beforepublishin Control". Becausepublishisprompt, workspace chat/Slack/native-harness runs get onlysearch— adding that half-sentence makes the example concretely teach the rule the section just introduced.
Also, "Workspace chat, the Slack agent, and native-harness runs withhold these tools" appears twice in the same section (once right after the prompt explanation, once in the closing paragraph); one can go.
Minor: the new paragraphs are single long lines while the rest of the file hard-wraps near 80 columns, which makes future diffs on those lines noisier.
There was a problem hiding this comment.
Mogplex PR Review
Status: Attention needed
Docs-only PR documenting that saved HTTP MCP servers now supply tools to web chat and Control. The structure is good — the new "Use a saved server in web chat" section, the "Where connection tools load" table, and the Integrations-vs-catalog disambiguators in connection-scope-and-overrides.mdx and settings.mdx all line up, and the new anchor link (#use-a-saved-server-in-web-chat) resolves to a real heading. No critical issues. Four things worth fixing before merge, all about precision in the permission semantics and one gap in the security guidance:
- "auto and approve both allow automatic calls" is counterintuitive and the accepted values are never listed in one place — a reader will very plausibly read
approveas "requires approval" and ship an auto-executing tool. - "explicit prompt approval mode" (stated twice, including the troubleshooting row) conflicts with the later statement that a server-level default of
promptalso makes tools Control-only. "Effective" is the accurate word. - The example config's summary sentence ("allows search and publish...") is surface-dependent — under the same page's rules, workspace chat withholds
publishbecause it isprompt. - The Security notes list was not updated for the behavior change: enabled saved servers now expose tools to every web chat and Control turn, with no project exclusion and no server-count cap, while secret headers are sent to a third-party public URL.
Also non-blocking: the PR depends on the unreleased app PR Mogplex/mogplex#522, so the approval-mode semantics above should be confirmed against that implementation before merge, and the pre-existing /extend/skills link on this page appears to be a 404.
Warnings
approvedocumented as auto-running is a footgun; list the full set of approval_mode values (content/docs/configure-and-extend/connections-and-mcp.mdx)
In the Extra JSON explanation: "A per-tool approval mode overrides the default.autoandapproveboth allow automatic calls."
Naming a value approve and then saying it runs without approval is the opposite of what most readers will assume — the natural reading is "this tool requires approval." Someone skimming could set "approval_mode": "approve" on a destructive tool believing they gated it, and instead get silent auto-execution in Control and workspace chat.
The page also never lists the accepted values in one place: auto, approve, prompt, deny, plus per-tool enabled: false, currently appear scattered across four separate sentences.
Suggestion: replace the scattered sentences with a small value table under the JSON example — value, what it does, which surfaces load the tool — and call out explicitly that approve is a synonym for auto rather than a gate. Please also confirm the value list and their semantics against the implementation in Mogplex/mogplex#522 before merging, since this page is the only place users will learn them.
-
"explicit prompt approval mode" contradicts the server-level default rule (content/docs/configure-and-extend/connections-and-mcp.mdx)
Two statements in the new section are in tension: -
"Tools with an explicit
promptapproval mode require Control, which can ask before a call." -
"A server-level default of
promptmakes every tool without a per-tool override Control-only."
The word "explicit" reads as "set per-tool in the tools map," so a user who set only default_tools_approval_mode: "prompt" will conclude the first rule does not apply to them. The same wording is repeated in the troubleshooting row: "Use Control for tools with an explicit prompt approval mode."
Suggestion: use "effective" instead of "explicit" in both places — e.g. "Tools whose effective approval mode is prompt (set per tool or inherited from default_tools_approval_mode) require Control." That also makes the troubleshooting row actionable for the server-default case.
-
Security notes not updated for the new always-on web chat exposure (content/docs/configure-and-extend/connections-and-mcp.mdx)
The Security notes section still addresses only Integrations and the catalog API (treat responses like.env, prefer project scope, exclude global MCPs per repo). None of that applies to saved servers, but the blast radius changed with this PR: -
An enabled saved server's tools now load on every web chat and Control turn by default, and per the new text they run automatically unless an approval mode is set.
-
Saved servers "apply across repos" and "Integration scope exclusions do not apply," so the per-repo containment advice in the existing bullets has no equivalent here.
-
The MCP limits section notes Integrations are capped at five per resolved scope "to protect runs from receiving an oversized or noisy tool surface," while "The MCP Servers catalog has no server-count cap" — that rationale now cuts against the uncapped catalog feeding the same chat surfaces, and a reader will notice the asymmetry.
-
"Saved secret headers stay hidden in the browser. Mogplex sends them to the configured MCP server when it connects" — worth stating plainly that those credentials leave Mogplex for a third-party public URL on each connection.
Suggestion: add two bullets to Security notes — (1) disable saved servers you do not want available on every chat turn, since there is no per-repo exclusion; (2) narrow the surface with enabled_tools/disabled_tools, and use prompt on destructive tools so they are Control-only. A one-line pointer from the MCP limits section explaining why the catalog is uncapped would also preempt the obvious question.
Suggestions
- Example config summary is surface-dependent and slightly overstates what loads (content/docs/configure-and-extend/connections-and-mcp.mdx)
The lead-in says the example "allowssearchandpublish, blocksdelete, and asks beforepublishin Control."
By this page's own rules, publish is prompt, so workspace chat, the Slack agent, and native-harness runs withhold it entirely — only search loads there. The sentence is accurate for Control but reads as universal.
Suggestion: "...allows search and publish in Control (asking before publish), blocks delete, and loads only search in workspace chat."
Separately: delete appearing in both enabled_tools and disabled_tools is explained immediately afterwards as a precedence demo, which is fine, but this is also the only copy-pasteable config on the page. Consider making the main example clean and showing the blocklist-wins case in a second two-line snippet.
- Pre-existing: /extend/skills link looks like a 404 (content/docs/configure-and-extend/connections-and-mcp.mdx)
Not introduced by this PR, so not a blocker. In the "Direction matters" follow-up paragraph: "Use Skills when the host needs guidance for driving the CLI..."
There is no content/docs/extend/ tree (the docs root meta.json has no extend entry), and next.config.mjs only redirects /extend/mcp-server, not /extend/skills. The Skills page appears to live at /cli/skills per content/docs/cli/meta.json. Cheap to fix while this file is already open.
- Merge ordering depends on an unreleased app change (content/docs/configure-and-extend/connections-and-mcp.mdx)
The description notes this depends on Mogplex/mogplex#522 and should merge after that app release — good call-out. Flagging only because the concrete numbers in the new text (eight-second Control deadline, six-second saved-server discovery budget, the approval-mode value semantics, "Codex sandbox runs: None yet") are not verifiable from this repo and will silently go stale if the app behavior shifts before release. Worth a final pass against the merged app PR rather than the current branch state.
This branch was successfully deployed
1 participant
Saved HTTP MCP servers now supply tools to web chat and Control as well as syncing to the CLI. Explain the public URL requirement, next-turn enable/disable behavior, and how saved tool restrictions and explicit approvals carry over.
Depends on Mogplex/mogplex#522; merge after that app release. Runtime coverage and troubleshooting now distinguish saved servers from Integrations, including startup deadlines and approval behavior.
Validation: lint, typecheck, 18 tests, and production build passed.