Notifications
Clear all
Topic starter
08/06/2026 4:21 pm
TL;DR: VSCode’s MCP walkthrough shows how installation friction, API key handling, tool discovery, unlimited tool growth, and context management shape developer adoption and security, according to WorkOS. The deeper lesson is that MCP becomes an identity governance problem once secrets, tool access, and runtime context are made easy to delegate.
NHIMG editorial — based on content published by WorkOS: From Pain Points to Solutions, How VSCode Solved MCP's Biggest Developer Challenges
Questions worth separating out
Q: How should teams govern MCP server installation in developer environments?
A: Treat MCP server installation as a controlled enrollment step, not a convenience action.
Q: Why do MCP tool pickers create governance risk even when users stay in control?
A: Tool pickers can turn one-off access into repeatable authority patterns.
Q: What breaks when MCP context handling becomes too compressed?
A: Auditability breaks first.
Practitioner guidance
- Treat MCP installation as an enrollment event Require explicit approval, logging, and ownership assignment when an MCP server is installed, especially if the flow captures API keys or other secrets.
- Inventory reusable tool bundles and chat modes Identify any saved tool combinations, preconfigured modes, or shared client profiles that let users reuse access patterns across sessions.
- Separate secret entry from freeform configuration Move API key handling out of manual JSON editing and into controlled input flows with validation, audit trails, and secrets management integration.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The step-by-step VSCode workflow for installing MCP servers and handling API keys during setup.
- The live demo of tool picker behaviour and reusable chat modes for context engineering.
- The developer-mode features, restart behaviour, and log visibility used to debug MCP servers.
- The specific sampling and resource-link mechanics that reduce context bloat in practice.
👉 Read WorkOS's MCP Night 2.0 recap on VSCode's developer experience fixes →
MCP tool installation and secrets handling: are controls keeping up?
Explore further
08/06/2026 5:56 pm
MCP usability work is really authority design work. When an MCP client makes installation, credential entry, and tool selection feel effortless, it is also reducing the friction that normally exposes access decisions. That matters because friction is often the last visible sign that a governance boundary exists. The field should stop treating MCP ergonomics as a separate layer from identity control. Practitioners should read easy setup as a signal to harden the enrollment and authorisation path.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What should security teams do when MCP usage starts spreading across many tools and modes?
A: They should define exposure boundaries for the tool classes each environment is allowed to surface, then review those boundaries as usage grows. Once a client can load very large tool sets, the risk is not just clutter. It is uncontrolled authority expansion across tasks, teams, and sessions.
👉 Read our full editorial: VSCode’s MCP usability fixes show where identity controls still lag
