Give every coding agent your full platform context with MCP

A coding agent that only sees one repository guesses about everything else. Connected to Orunbase over MCP, it reads the same catalog, runs, logs, tasks and playbooks as your team, with its own credential and under your access rules.

7 November 2026 · 7 min read · The Orunbase team

Full platform context means a coding agent can ask your platform what it would otherwise have to guess: who owns a service, what depends on it, what ran in production and why it failed, which task a change belongs to, and how your team does things. Orunbase serves that context over the Model Context Protocol (MCP), so Claude Code, Cursor, VS Code or any MCP client can query your workspace's catalog, runs and logs, task contracts and playbooks directly, and deliver its work as a pull request that carries its lineage. Every call uses the agent's own credential and your workspace's access rules.

What does a repository not tell an agent?

Open any repository and an agent can read its code, its tests and its config. That is a lot, and it is not enough. Most of the questions that decide whether a change is right are about things outside the files:

Ownership. Who owns this service, and who should review a change to it?
Dependencies. What else breaks if this shared package changes?
Delivery. What is running in stage and prod right now, and did the last deploy succeed?
Failures. Why did last night's run fail, and in which job?
Intent. Which task is this change for, what is it allowed to touch, and what does done mean?
Practice. How does this team branch, commit and open pull requests?

Without answers, an agent infers them from whatever it has read, or someone pastes them into the prompt. Both are slow and both drift. MCP lets the agent ask the platform instead.

What can an agent ask?

Orunbase's MCP server exposes the platform as task-shaped tools. The read tools change nothing and can be called freely. The main ones, by the question they answer:

The agent wants to know	Tools
Which workspaces and repositories can I see?	`whoami`, `workspaces_list`, `projects_list`
What is this service, who owns it, what does it depend on?	`catalog_search`, `catalog_get_entity`, `catalog_read_doc`
What ran, and what failed?	`runs_list`, `runs_get`, `runs_read_logs`
How is this component or epic doing over time?	`insights_get`
What is this task, what may it touch, how far along is it?	`task_get`, `task_list`, `policy_preview`
Where in our docs and specs is the answer to this question?	`workspace_context`, `workspace_expand`
How does this team work?	`skills_list`, `skill_get`
Why can't I do this, and who can?	`access_explain`
Which settings, flags and secrets exist here?	`config_read`, `secrets_list` (metadata only)
What changed, and who changed it?	`events_search`, `audit_search`

The catalog is not a separate inventory someone maintains. It is derived from the same component.yaml files, intent and CODEOWNERS that the planner reads, so what the agent learns about a service is what will actually be built and deployed.

Answers that cite their sources

workspace_context takes a question in plain language and returns passages from your workspace's own material: the component graph, docs attached to catalog entities, repository overviews and epic specs. Each passage cites the entity it belongs to, the path it came from and the commit it was read at. workspace_expand then walks the component graph outward from an entity, to what it depends on or what depends on it.

The ranking is a published formula, not a hidden model: how many of your words a passage contains, how close it is in meaning, and four small bonuses, with a why[] breakdown on every result. An agent can quote a passage and say exactly where it came from, which is the difference between context and a confident guess.

What can an agent do?

Reading is most of it. When an agent needs to act, a small set of tools write:

Open the pull request. pr_open, served by the local orun mcp serve inside a repository checkout, opens the pull request with its lineage: the branch on the orun/<KEY>-<slug> grammar, pushed, with the manifest block in the body naming the task and the playbook revisions the session followed.
Plan the work. epic_create, milestone_create and task_create let an agent lay out work as an epic with milestones and tasks, each task with its contract attached.
Change platform settings. project_create, environment_create, flag_set, webhook_create, webhook_delivery_replay and member_invite cover the rest.

What an agent cannot do is as important. There is no tool to set a task's status. A task reaches done because the platform observed a merged pull request whose contract gates passed, so an agent cannot mark its own work finished. And no tool reads a secret's value.

A session, step by step

Here is how a session might go when a developer asks an agent, "Why did last night's production deploy fail, and can you fix it?" The workspace and names are illustrative; the first three steps follow the order Orunbase's own playbook recommends for a failed delivery.

Find the run. runs_list for the workspace, newest first, shows the failed production run.
See the shape of it. runs_get returns the run's plan DAG with each job's status: the api component's deploy job failed in prod; stage passed.
Read the failure. runs_read_logs on that job pages through its logs and finds the error: a migration expected a column that stage had and prod did not.
Understand the component. catalog_get_entity for component:default/api shows its owner and what it depends on. workspace_context with "how do database migrations run in prod?" returns the runbook passage, cited to its file and commit.
Bound the fix. task_create opens a task with a contract: the goal, affects limited to the migrations package and the api component, and what done means.
Make the change. The agent edits the code inside that ceiling and runs the repository's own tests.
Deliver it. pr_open opens the pull request on the task's branch with its manifest. The plan shows exactly what will run, the orun/compliance check verifies the lineage, and the owner from step 4 reviews it.

At no point did the developer paste a log, a runbook or an owner's name into the prompt. And nothing in the tool set deploys, reads a secret or marks the task done: the fix ships the way every change does, through review, the plan and CI.

How is it kept safe?

An MCP server that can see your whole platform has to be at least as careful as your console. Orunbase's is built as a client of the public API, never a back door:

The agent's own credential. Locally, the server rides your orun auth login session. Remotely, it uses OAuth from the client or a workspace API key. There is no separate, broader MCP credential.
Your access rules. Every call is checked by the same role-based access control as any other client. Read tools need the viewer role; writes need builder or above. A key minted as viewer can only read.
Read-only when you want it. orun mcp serve --read-only drops the platform write tools from the list and blocks them at execution. The remote server is read-only today.
Secrets stay write-only. Tools can list secret metadata, such as keys, versions and rotation state, never values.
Everything is audited. Every tool call lands in the audit log tagged x-client-surface: mcp, is rate-limited at the API edge, and is metered in your workspace's usage.
Retries are safe. Write tools carry an idempotency key per attempt, so an agent that retries does not create things twice.

How do you set it up?

Install the orun CLI and sign in once:

curl -fsSL https://raw.githubusercontent.com/sourceplane/orun/main/install.sh | sh
orun auth login

claude mcp add orun -- orun mcp serve

Run it from inside a repository checkout and the agent also gets pr_open. To check the setup, orun mcp doctor verifies the binary, your sign-in, the workspace it resolves and the connection to Orunbase, then prints the exact line to register. orun mcp tools prints the tools your binary serves.

For Cursor, VS Code and other clients, and for the remote server that hosted agents and CI can reach over Streamable HTTP, follow the MCP setup guide. The MCP server is available on every Orunbase plan, Free included.

Playbooks as versioned skills

Context is not only facts. It is also how your team works. Orunbase serves playbooks as skills: how to branch, commit and open a pull request, how to plan an epic, how to diagnose a failed run. skills_list returns each skill with a content-addressed revision, and skill_get returns its body at that revision. The pull request manifest records which revisions a session followed, so a reviewer can re-read the exact playbook the agent ran under, and the compliance check fails a pull request that names a revision the registry never published.

In short

A repository tells an agent about itself; the decisions that make a change right depend on ownership, dependencies, delivery history and intent.
Orunbase's MCP server gives agents the catalog, runs and logs, task contracts, cited answers from your own docs, and your playbooks.
Writes are few and deliberate: open the pull request with lineage, lay out tasks with contracts, change settings. Nothing sets a task's status or reads a secret.
Every call uses the agent's own credential, your access rules, the audit log and idempotent retries.
Set it up with orun auth login and claude mcp add orun -- orun mcp serve, and check it with orun mcp doctor.

For why this matters, read why agentic development needs platform discipline. For the foundation the context rests on, read what platform discipline is.