One MCP for your whole engineering knowledge.
Your coding agents query Oracus.ai directly — every repo, every ticket, every architectural decision in your org, from one mount. No per-developer install, no per-project index, no version drift.
One mount. Every repo. Every ticket.
Coding agents on big codebases spend most of their token budget rediscovering structure with grep, find, and Read on every session. Mount Oracus.ai as an MCP server and the agent asks the index instead — answers come back pre-narrowed, cited, and cross-repo by construction.
{
"mcpServers": {
"oracus": {
"type": "stdio",
"command": "oracus-mcp",
"env": { "ORACUS_URL": "https://oracus.your-org.internal" }
}
}
}That's the whole install. Restart your agent and the tools show up. The same instance serves every developer, the CI bot, the PM in team chat, and the support engineer in Slack — all reading from the same index.
What an agent can ask
Concrete questions Oracus.ai answers in one tool call — the kind of thing your agent would otherwise spend twenty grep+read round-trips approximating.
› Brief me on the payments service before I touch it.
Returns: stack, what it exposes (HTTP routes, RPC methods, events), what it depends on (services, libraries, infra), ownership. Replaces 10+ file reads.
› Where in the org is JWT verification implemented?
Semantic search across every ingested repo, merging code symbols and spec/architecture chunks in one ranked answer. Top hits include exact file:line pointers to functions you can read with one follow-up call.
› Who calls `chargeCard` across the codebase?
Symbol-precise call sites — every caller across repos, with file path, line, and signature. Cross-repo by construction; beats grep on JS/TS/Go/Python/Java where static analysis resolves the reference cleanly.
› Show me the implementation of `ListProducts` and what it depends on.
Returns the source body (read from the checked-out repo on disk), the symbol's signature, and its immediate callers and callees — replaces a Read + grep round-trip with one tool call.
› If I change the orders service, what breaks?
Cross-repo dependencies grouped by edge kind (HTTP, RPC, event, shared-db) with cautions for the most likely break vectors. For symbol-level blast radius, callers / node cover the in-repo precision.
› What ticket spawned this code, and who owns it?
Pulls from the linked Jira/Linear + GitHub graph, not from filenames or guesses. Answers like a senior engineer who's been on the team for two years.
One MCP — different by construction
Most code-MCPs run on a developer's laptop and index one repo at a time. Oracus.ai is the opposite shape — one centralized index across everything your org ships, queried by every agent. Four properties that fall out of that shape:
One Oracus instance, one index, every agent and every developer querying the same source. No per-developer install, no version drift, no "did dev A index repo X today."
Service-to-service edges across every repo your org runs — derived from k8s manifests, Helm, proto, OpenAPI, package manifests. Cross-repo questions are a single tool call, not a manual stitch.
Tickets, design docs, OpenAPI contracts, ownership from CODEOWNERS and catalog metadata — all fused with the code index. The agent can answer questions that span what lives in your editor and what lives in Jira or Linear.
Your agent can ask about any repo Oracus has ingested, even ones the developer never pulled to their laptop. The org's knowledge isn't gated on which clones happen to be on whose disk.
Tools the MCP exposes
Six tools, scoped to the discovery, location, impact, and code-intel questions that account for most of an agent's token spend. One MCP, one config — no companion install for symbol-level work.
oracus_summarize Architectural brief on a repo before you read any source — stack, what it exposes, what it depends on, infra, ownership.
oracus_locate Find where a concept lives across every indexed repo. Returns code symbols (with exact file:line), source files, and spec/architecture chunks — merged in one ranked list so the most relevant hit wins regardless of kind.
oracus_impact Service- and endpoint-level cross-repo impact. Inbound and outbound dependencies grouped by edge kind (HTTP, RPC, event, shared-db, library), with cautions for the most likely break vectors.
oracus_callers Every call site of a function / method / class across the indexed graph. Replaces grep when you want CALL SITES specifically — no comment/string false positives.
oracus_callees What this symbol calls. Trace a function's downstream dependencies before refactoring its body.
oracus_node Read a symbol's full source body (from disk) plus its signature, callers, and callees — one tool call instead of a Read + grep round-trip.
Each tool returns cited results — file pointers, repo slugs, ownership identifiers — so the agent (and the human reading the agent's answer) can verify every claim against the source.
Polyglot, by default
Oracus.ai's internal code-graph extractor reads 20+ languages and recognizes routes from 17 web frameworks. Polyglot orgs get one unified graph regardless of which service is in which language — and one MCP that answers symbol-level questions across all of them.
TypeScript, JavaScript, Python, Go, Rust, Java, C#, Swift, Kotlin, Ruby, C, C++, Objective-C, PHP, Scala, Dart — and more. Cross-language flows like Swift ↔ Objective-C bridging, React Native native modules, and gRPC service stubs are stitched together in the same pass.
Django, Flask, FastAPI, Express, NestJS, Spring, Rails, Gin, chi, Axum, actix, Rocket, ASP.NET, Vapor — plus React Router, SvelteKit, Vue Router, Nuxt, Astro. Ask "where is the /checkout route implemented" and Oracus.ai returns the handler function, not the routing file.
Self-hosted, like the rest of Oracus.ai
The MCP server is part of the same container you already run. No new infrastructure, no extra ops surface. Your agents connect to an Oracus.ai instance inside your network — code, tickets, and ownership data never leave your servers.
The agent talks directly to your Oracus.ai instance. No SaaS middleman holds your code graph or routes your queries.
Claude Code, Cursor, Codex CLI, opencode — anything that speaks stdio MCP. One config block, no per-agent adapters.
Every connector you've already wired into Oracus.ai — git repos, Jira, Linear, GitHub, JUnit, files — becomes context the agent can query through the same MCP.
Every result carries the repo, file, or ticket it came from. The agent's answer stays grounded; the human reviewer can click through.
Wire it into your agents
Setup snippets for Claude Code, Cursor, and other MCP-compatible agents are in the docs. If you don't yet have an Oracus.ai instance, start with the self-host request — the MCP server is part of every deployment.