A platform engineer assigns a GitHub issue to Copilot. Overnight, the coding agent opens a pull request. The diff is coherent, the tests pass, and the PR description reads like a competent junior engineer wrote it. Review starts in the morning. Within ten minutes, the senior reviewer notes that the agent introduced a new retry pattern instead of using the shared library, imported a database client that the team deprecated three sprints ago, and wrote a logger wrapper that duplicates existing functionality. The agent did good work. It did not do the team's work.
That gap is the gap between a general software-engineering assistant and one that has read your team's declarations. Copilot is the first; Ribo makes it the second. What makes this integration distinct from a simple IDE plugin is that Copilot runs in two places, and each place needs its own wiring.
Two surfaces, two wiring moments
Copilot is not one product. The IDE agent runs on a developer's laptop inside VS Code, Visual Studio, or a JetBrains IDE. The coding agent runs on GitHub's servers, taking issues as input and producing pull requests as output. The two share a brand. They do not share a configuration surface.
For the IDE agent, MCP configuration is per-developer. The config lives in the workspace or user settings, and each developer controls what external servers their local Copilot can reach. For the coding agent, MCP configuration is per-repository or per-organization, managed by an admin in repo or org Copilot settings. A developer cannot wire the coding agent to Ribo on their own. An admin has to do it once, and then every issue that gets handed to the coding agent for that repo uses the same configured MCP servers.
Most teams we see wire the IDE agent first, because it is the fastest path to value and requires no admin. Then, once they see what review-quality completions look like with declared context, they wire the coding agent as the second move. Both are covered below.
What changes when Copilot can ask about the system
GitHub's Copilot MCP integration lets the agent call out to external MCP servers during its work. Point that at Ribo and Copilot gains a scoped, read-only view of the system's declared identity: intent artifacts that define what components do, contract artifacts that define their interfaces, algorithm artifacts that govern how computations behave, integration artifacts that name the external boundaries, and so on.
Take the overnight-PR scenario. Without Ribo, the coding agent reads the repo, infers patterns, and writes code that matches the patterns it can see. Idiomatic, but blind to the decisions that live outside the code. With Ribo mounted, the agent searches for declared artifacts related to the issue, retrieves the integration artifact that names the canonical database client, finds the algorithm artifact that declares the shared retry policy, and reads the constraint artifact that forbids new logger wrappers. The PR that lands in the morning uses the right client, the right retry pattern, and no duplicate logger. Review moves from "correct the agent's drift" to "approve the agent's choice."
The same effect shows up in the IDE, just at smaller grain. Instead of rewriting an entire pull request, developers stop declining one-line suggestions every few minutes.
Role-appropriate projection for IDE and coding agent
Copilot's two surfaces have different audiences, which means they can tolerate slightly different projections. Ribo's DNA splits into thirteen layers: intent, contract, algorithm, evaluation, escalation, pace, monitor, glossary, integration, reporting, compliance, constraint, and tradeoff.
For the IDE agent, expose seven: intent, contract, algorithm, glossary, constraint, tradeoff, and integration. Intent tells the agent what the component does. Contract tells it what interfaces it promises. Algorithm tells it how computations must behave. Glossary translates team vocabulary. Constraint and tradeoff record what the system must not become. Integration names external system boundaries. Withhold compliance, evaluation, pace, monitor, reporting, and escalation; these are not authoring concerns.
For the coding agent, extend the projection to eight by adding evaluation. The coding agent opens pull requests that will go through review, which means it benefits from knowing how correctness is measured before it writes the code. A coding agent that can read evaluation artifacts produces PRs that are already checkable against the same rubric the reviewer will use, reducing the back-and-forth.
Ribo mints a separate bearer token per integration, with an allowed_kinds list scoping which layers each integration can read. Two tokens for Copilot, one for each surface, keeps the projections clean.
How to wire it up, IDE side
First, mint the IDE token. In the Ribo console, go to Agents, create an agent named copilot-ide-<repo>. Set scopes to artifact:read. Set projectIds to the Ribo project covering this repo. Set allowed_kinds to the seven-layer IDE projection: intent, contract, algorithm, glossary, constraint, tradeoff, integration. Capture the bearer token.
Second, add Ribo to Copilot's IDE MCP config. In VS Code, the canonical place is .vscode/mcp.json at the repo root for a workspace-scoped config, or the user settings.json under "mcp.servers" for a global config. The entry shape:
| Field | Value |
|---|---|
| Top-level key | servers (workspace file) or mcp.servers (user settings) |
| Server key | ribo |
url | https://mcp.ribo.dev/context/mcp |
| Authorization | Bearer token from the Ribo console, passed via requestInit.headers.Authorization |
VS Code infers HTTP transport from the presence of url; no explicit type field is required. Save the file, reload VS Code, and confirm Copilot lists Ribo among its tools in the agent-mode tool picker. Suggestions from agent mode will now include Ribo searches where relevant.
How to wire it up, coding-agent side
The coding agent is wired through GitHub's UI, not a file. Open the repository settings, navigate to Code & automation → Copilot → Cloud agent, and find the MCP configuration section. Add a server with the same URL (https://mcp.ribo.dev/context/mcp), type http, and paste the bearer token into the headers field.
Two coding-agent-specific notes. First, the coding agent does not support OAuth for remote MCP servers; header-based bearer auth is the only option today, which is fine for Ribo's scoped-token model. Second, the coding agent requires a tools field in the server configuration. Set it to ["*"] to expose all of Ribo's read tools, or narrow to ["search", "get_artifact", "list_artifacts", "get_relationships"] for explicit allowlisting. GitHub's coding-agent MCP docs are authoritative for the current schema.
What the review-level change looks like
Before wiring Ribo into the coding agent, a typical PR from Copilot reads like a reasonable implementation written without any internal context. After wiring, the PR description starts citing artifacts. "Uses the shared PaymentsClient per integration artifact int_payments_v4," "retries routed through the policy declared in alg_retry_exponential," "error envelope matches contract ct_error_v3." Review time drops because the reviewer no longer has to ask whether the agent considered the team's prior decisions. The PR says it did, with citations.
In the IDE, the shift is quieter but cumulative. Developers stop developing a habit of rejecting the first suggestion. When the first suggestion already fits, they accept it, and the cognitive cost of constant pattern-correction goes away.
What it's worth
Copilot already ships fast code. The question is whether the code is yours. Every PR the coding agent opens that requires harmonization work is a PR where the agent's fast output consumed your slow review. Every IDE suggestion you decline is a micro-interrupt. Ribo is the piece that turns "fast general code" into "fast code that fits." Wired into both surfaces, the same declared source of truth informs authoring on the laptop and authoring in the cloud, and the gap between the two closes.
Copilot writes. Ribo says what counts as written. Two surfaces, one declaration, one shape of review.