MCP, Spaces, and Spark

This lesson covers three ways to give Copilot more to work with. MCP connects it to external systems. Spaces collect the sources for a recurring question. Spark builds a working prototype from an application brief.

More capability can make an answer or prototype look more authoritative than it is. Each tool therefore needs a matching check. Watch the external tool run, trace Space claims back to their files, and test Spark behavior before asking for refinements.

MCP connects Copilot to external systems

MCP (the Model Context Protocol) is a standard way for an AI application to connect to external tools and data. Here, VS Code and Copilot are the host. An MCP server exposes capabilities the host can discover and use, such as searching issues, reading documentation, or running a controlled operation. The server is not a language model and doesn't replace Copilot. It's a controlled interface to another system. A typical exchange: you ask for unresolved release blockers, Copilot picks a server tool like list_blockers, sends it structured input, the server returns structured data, and Copilot formats an answer from that evidence.

Two things about that server deserve constant attention. First, classify every tool by effect: a read-only tool returns information without changing anything, while a mutating tool creates, updates, or deletes data. A server that's safe to connect is not automatically safe to use for every operation. That split gives you two separate trust decisions: connection trust (should VS Code start or contact this server?) and operation trust (should this specific tool call run with this input?). Second, note the transport: a local process runs on your machine via a command and arguments, while a remote server is reached through an HTTP endpoint its owner supplies.

Configuration lives in layers. A user configuration is private to your install. A repository configuration commonly sits in .vscode/mcp.json so contributors share the same server definition. Organization or enterprise governance controls whether centrally managed users may use servers at all. That last point matters: committing an endpoint to .vscode/mcp.json shares a connection, but it does not approve the server or authorize everyone to use it. Approval is what a registry (a catalog of reviewed servers) and an allowlist (enforced policy on which servers are allowed) provide, and no committed config ever contains a secret.

Tool activity proves an MCP run

A fluent blocker report can appear to come from your issue tracker even when Copilot never called the MCP tool. Look for observed server and tool activity. Ask the response to name the selection, watch the call or approval request, and treat silence as a discovery problem. The failure may sit in configuration, process startup, tool discovery, policy, or authentication.

After the call, audit the result one field at a time. Every displayed value needs a matching property in the server response. If there isn't one, label the field "Not returned by server." An empty blocker list can still prove discovery when the expected tool ran. A polished table without a call proves nothing about its source.

Server governance continues after approval. Record its capabilities and owner, decide who may connect, approve runtime calls, test allowed and denied cases, and review it again when it changes. A server can keep its name while adding a tool such as close_issue. That new mutating capability invalidates the earlier read-only classification, so access and enforcement need another pass.

Spaces curate the working context

A Copilot Space is a reusable place to organize the context Copilot should use for a recurring question: a named evidence package, not a new model or a coding agent. The value isn't the container. It's the discipline of choosing sources that can answer one question and stating how Copilot must use them. A curated request ("use the architecture decision, the local-dev guide, and current issues to explain how a contributor runs the service and flag missing setup") beats "tell me everything about this project," because it draws an evidence boundary that makes the answer inspectable and its gaps visible.

Keep a Space honest with a claim-to-evidence habit. Read every important response as a set of claims and carry each through four stages: which supplied artifact could support it, what guidance told Copilot to use that artifact, what exact claim Copilot made, and whether the artifact confirms, contradicts, or omits it. Classify the result as confirmed, conflicting, or missing, and never upgrade a likely value into a confirmed fact without saying so. If the source says port 4000 and the answer says 3000, that's a conflict, not a rounding error. If no source states a port, that's missing, and "the source doesn't say" is not the same as "there is no port."

The trap to avoid is the citation that looks like proof. A filename printed next to a claim proves nothing on its own. You still open that file and compare the actual command, value, or status. A Space rewards curation and verification. It does not do them for you.

When do you reach for Spark instead?

Spaces organize evidence. GitHub Spark does something different: it turns a natural-language application idea into a web-app prototype, no code required. It changes where you start. Instead of files, frameworks, and components, you begin with a user problem and a brief. A strong brief defines the users, the tasks they complete, the data shown or collected, the actions and states, the acceptance criteria, and the deliberate exclusions. Spark was announced in public preview for Copilot Pro+ subscribers in July 2025. If it isn't available to you, you can still write the brief and test plan and not claim you generated an app.

The habit that makes Spark useful is testing before refining. A generated app can look finished and still get validation, filtering, persistence, or empty states wrong. A polished interface is not evidence that behavior is correct. So write your expected results first ("a blank submission shows validation," "clearing the filter restores the full list"), run each one against the prototype, and record concrete observations ("two rows remained visible"), not vague impressions. Then refine one failed behavior at a time, preserving what already works, and rerun the neighboring tests to make sure your fix didn't break them.

Spaces and Spark can even chain: a Space can help you produce an evidence-backed product brief, and Spark can explore an application shape from it. They share a rule with everything above: generation is a starting point, not a verdict. You test the flows and treat sharing or deployment as a separate, deliberate decision.