You write the method signature for chargeCustomer. Cursor offers a body: open a Stripe client, create a PaymentIntent, handle the webhook, log the outcome. The completion is clean. The tests pass. Two weeks later, a code reviewer asks why payments are routing through a new Stripe initializer instead of the team's shared payments service. Cursor did not know the team has a shared payments service. It completed against a reasonable general pattern. You committed against your actual architecture.
The completion was not wrong in any way that a linter can catch. It was wrong at the level of what this system is. Cursor is great at the first kind of correctness. It has no idea about the second, because it has never been told. That is what MCP fixes.
The completion is only as good as the context it had
Every serious Cursor user has felt this. The model is competent. The suggestions are plausible. And still, periodically, the IDE proposes a pattern that violates a decision nobody ever wrote down in a form the IDE could read. You reject the suggestion, type the right thing, and move on. The interrupt costs are small individually and enormous in aggregate.
The fix is not a better model. It is better context. Cursor already reads your open files, your tabs, your recent edits. That is the local view. What it cannot see is the system view: what the component is supposed to do, what it must not do, what other components expect of it, what the team has already decided about the shape of change. Those are not in the open files. They live in Slack threads, expired design docs, and the heads of three senior engineers.
MCP makes that system view reachable. Cursor supports remote MCP servers via a simple config file, which means the IDE can now call out to external tools for context during chat and agent mode. Point it at Ribo and the context it was missing becomes queryable.
What changes when Cursor can ask about the system
Ribo exposes a small set of read tools over MCP: search the artifacts that govern an area, retrieve a specific declaration, list artifacts in a project, walk the relationships between them. When Cursor's agent mode needs to make a design decision, it no longer has to infer. It can ask.
Take the chargeCustomer scenario. With Ribo mounted, Cursor's agent searches for artifacts related to payments, finds the integration artifact declaring Stripe as the payment provider, finds the contract artifact for the internal PaymentsService, and sees the intent artifact stating that all charge flows route through that service for auditing. It completes the method by calling payments.Charge(ctx, …) instead of initializing a new Stripe client. The completion is not just plausible; it is consistent with the declared architecture.
The shift for the developer is subtle but material. You stop pulling Cursor back from the wrong pattern, and the suggestions feel like they were written by someone who has read the internal docs. Because, in effect, they were.
Role-appropriate projection: what Cursor should see
Not every layer of your declared identity belongs in a coding agent's context. Ribo's DNA splits into thirteen kinds: intent, contract, algorithm, evaluation, escalation, pace, monitor, glossary, integration, reporting, compliance, constraint, and tradeoff. An IDE agent needs the ones that shape how code gets written, not the ones that describe how the system is observed in production.
The projection we recommend for Cursor is seven layers: intent, contract, algorithm, glossary, constraint, tradeoff, and integration. Intent tells the agent what the component is supposed to do. Contract tells it what interfaces this component promises and consumes. Algorithm tells it how a computation must behave. Glossary translates the team's vocabulary. Constraint names what the system must not become. Tradeoff records the decisions between competing options. Integration names the external surfaces the system talks to.
The six layers a Cursor agent does not need: compliance (not the IDE's job to enforce), evaluation (a review-time concern), pace (release cadence, not authoring), monitor (runtime observability), reporting (upstream cadence), and escalation (incident routing). Keep the projection narrow. A smaller surface reduces token cost on every MCP call and reduces the blast radius if the token leaks off a developer's laptop.
Ribo mints a separate bearer token per integration. A Cursor token built with the seven-layer projection above cannot read compliance or monitor artifacts even if the model asks. One source of truth, projected differently for every tool that touches it.
How to wire it up
Two surfaces, one token between them.
First, mint the token in the Ribo console. Go to the Agents page, create a new agent named after the repository you are wiring up (something like cursor-<repo-name> keeps audit logs readable). Set scopes to artifact:read. Set projectIds to the Ribo project covering this repo. Set allowed_kinds to the seven-layer projection above: intent, contract, algorithm, glossary, constraint, tradeoff, integration. Create the agent. Ribo returns a plaintext bearer token exactly once; stash it in your secrets manager.
Second, add Ribo to Cursor's MCP config. The file lives at ~/.cursor/mcp.json for a global config or .cursor/mcp.json at the repo root for a per-project config. Use the project-scoped file when the repo has its own Ribo project; use the global file when a single Ribo project covers multiple repos. The entry takes this shape:
| Field | Value |
|---|---|
| Server name | ribo (or your internal naming convention) |
| URL | https://mcp.ribo.dev/context/mcp |
| Authorization header | Bearer token from the Ribo console |
Cursor's MCP docs cover the current config schema and should be considered authoritative for any field names that change. Once saved, open Cursor's settings, confirm the Ribo server shows as connected, and you are done. The agent will call Ribo's search and retrieval tools during chat and agent-mode sessions, citing artifacts in its explanations.
What the completions look like
The change shows up in the boring places first. A developer asks Cursor to add a new endpoint to a service. Without Ribo, the suggestion is a reasonable REST handler, stylistically consistent with nearby code. With Ribo, the suggestion routes through the middleware the team declared on the contract artifact, uses the error envelope the glossary artifact defines, and imports the helpers the integration artifact names as the canonical clients for the downstream systems the endpoint will call.
None of that is visible in the diff. It is visible in the absence of the review comment that would otherwise arrive two days later asking why the developer did not use the existing pattern. The pattern is now the default suggestion, because the IDE has seen the declaration that made it the pattern.
What this is for
Most developers already tolerate a steady rate of almost-right suggestions from Cursor. The rate is low enough to ignore and high enough to compound. Every accepted suggestion that violates an undeclared architectural decision becomes a small amount of drift, and drift only shows up in aggregate, usually when a new engineer joins and cannot explain why the codebase has three ways of doing the same thing.
Ribo's job is to make the architectural decisions declared, queryable, and citable. Cursor's job is to use that context when it generates. Hook the two together and completions stop being guesses. They start being moves the team has already agreed to.
Cursor suggests. Ribo says what the system is. The IDE stops being a stylist and starts being a colleague who has read the docs.