Activating MCP Extensions... Skip or Wait?

Seeing activating mcp extensions... skip usually means VS Code is still starting MCP servers, so check before skipping. Open the server configuration and confirm the command it launches. Then read the server output for the actual error. This guide gives the order of checks and says which problems a checklist will not fix, so you stop waiting on a server that cannot start.

What does activating mcp extensions... skip mean in VS Code?

The message reads like a progress line with an escape hatch. VS Code is telling you it is bringing up the extensions and MCP servers your setup depends on, and it offers a way to carry on without waiting. It does not say that something failed, and it does not say that something succeeded. That is why it feels ambiguous.

I cannot tie the wording to a single cause in a specific VS Code version, and nothing here pretends to. What you can do is treat the line as a prompt to look at three things: the server entry, the command behind it, and whatever the server prints while it starts.

If you are new to the setup, the guide on adding an MCP server to VS Code shows what a healthy entry looks like. Compare it with yours before you start changing settings at random.

Why can MCP startup look stuck?

An MCP server is a separate process that the editor launches and then talks to. If that process never starts, starts and exits, or starts and waits for something, the editor has nothing to show except the activating line. From the outside, a server that is slow, a server that is waiting on input and a server that crashed can look the same.

That is the useful way to read a long wait: it narrows the problem to the process, not to the editor itself. The editor reached the point of launching something, and the question is what that something did next.

The model of tools, resources and prompts that a server exposes is covered in MCP tools, resources and prompts explained. It helps to know that a server only becomes useful after it has started and announced what it offers. Until then, the editor has nothing to list, which is why a stalled start leaves your tool list empty.

How do I check the server configuration and the command it launches?

Start with the entry for the server you expect to see. Confirm that it names a command, that the arguments are in the right order and that any required value, such as a token, is present. The full file format is in the VS Code mcp.json schema with examples, which is the reference to hold your own file against.

Then take the command out of the editor and run it yourself in a terminal. For Context7, the project's documentation gives the direct command npx -y @upstash/context7-mcp. For the GitHub server it is npx -y @modelcontextprotocol/server-github. If the command fails in a terminal, it will fail the same way under the editor.

• Is the command spelled exactly as the server's documentation gives it?
• Is every required credential set, and is it the right kind?
• Does the same command print an error when you run it by hand?

Credentials deserve a second look. The GitHub server authenticates with a fine-grained personal access token, and its documented pitfall is that the all repositories toggle does not include private repositories by default. A missing scope will not usually stall startup, but it produces confusing results later, so settle it now.

How do I read the MCP server output and logs?

The server's own output is the most direct evidence you have. Whatever the process prints on startup, whether a banner, a missing-variable complaint or a stack trace, tells you more than the activating line ever will. Open the output for the server in the editor and read from the top, not from the bottom, because the first error often causes the later ones.

Look for three patterns. No output at all suggests the command never ran or is waiting. A short error followed by silence suggests the process exited. Normal startup lines followed by no tools suggests the server is up but the editor has not finished the handshake.

The walkthrough on debugging an MCP server in VS Code goes deeper on reading these logs. Whatever you find, copy the exact first error line before you change anything, so you can tell later whether your change altered it.

When is skipping or restarting the server the right move?

Skipping is reasonable when you do not need that server for the task in front of you. If you are editing code and only the MCP tools are affected, carrying on costs you nothing except those tools. Skip when the output shows a clear, known problem you cannot fix right now, such as a credential you do not have on this machine.

Restarting is reasonable after you have changed something: corrected the command, added a missing value or fixed a path. A restart with no change to the configuration only repeats the same attempt. I would not claim that any one setting or restart always clears the message, and you should be wary of any advice that does.

A simple rule works. If you have an error line, fix it and restart. If you have no error line and no need for the server, skip. If you have no error line and you do need the server, go back to running the command by hand and read what it prints.

Which problems will this checklist not fix?

A checklist cannot repair a server that is broken at the source. If the command runs by hand and still fails, the fault is in the server, its dependencies or your machine, and the right place for that is the project's own issue tracker and documentation. Editor-side checks only rule out the part you control.

It also will not settle questions about permissions. A server that starts cleanly can still return nothing useful if its token lacks access, which is a different problem from a stalled start. MCP server permissions and scopes is the place to look for that.

Finally, it will not tell you whether a server is trustworthy. A clean start says nothing about what a server does once it runs. Before you install an unfamiliar one, the steps in how to audit an MCP server before install are worth the few minutes.

Which well-documented server can I test with next?

When you are unsure whether the fault is your setup or one particular server, test with a server whose launch command is clearly documented. Context7 is a reasonable candidate.

If Context7 starts cleanly through the same configuration route, your editor setup is probably fine and the earlier server is the problem. If it stalls the same way, the fault is more likely in your environment or configuration, and that is useful to know.

Another option is GitHub, which the directory lists with 9 tools such as list_issues and get_file_contents. Give it the smallest token scope that works, read-only for repositories and issues, until you have confirmed the server starts and behaves as expected.