RigelProductRigel MCP

Rigel MCP

Give every agent the whole chart.

One MCP entry gives Claude Code, Cursor or any MCP client 20 read-only tools over the services, contracts, consumers and callers Rigel has charted. And Rigel's own agents use your MCP servers in return.

Get early access Explore the 20 tools

Connect

# connect any agent in one line
$ claude mcp add --transport http rigel https://rigel.internal.example/mcp

read-only tools

tool groups

transports: stdio, HTTP

Runs once Rigel is installed in your network. HTTP transport Beta: no built-in auth yet, so keep it in-cluster or behind your authenticating proxy. Endpoint auth Coming soon.

01 · Both directions

MCP out, and MCP in.

Your agents read Rigel's chart. Rigel's agents call the servers you register. Same protocol, both ways.

Rigel centralizes cross-repo application knowledge, workflows, architecture and design patterns, and infra conventions, so agents across a microservice estate — tens to hundreds of repos — build consistently.

→ out · 20 read-only tools to your agents · → in · your MCP servers to Rigel's agents

→ out · your coding agents

Claude Code — claude mcp add
Cursor — ~/.cursor/mcp.json
VS Code — .vscode/mcp.json
Any MCP client — stdio or HTTP

Rigel · the chart

The chart lives in Postgres + pgvector. Your agents query it through 20 read-only tools; Rigel's agents call out through an allowlist per agent, with editing built-ins banned.

→ in · your MCP servers

Slack MCP — PR lifecycle threads
GitHub MCP — deploy risk digest
Postgres MCP — bundled · read-only
Any server you register — stdio or HTTP

View as list

Out: Claude Code, Cursor, VS Code or any MCP client connects to Rigel MCP over stdio or Streamable HTTP and gets 20 read-only tools over the chart.
The chart: one store in Postgres with pgvector. Your agents and Rigel's agents query it through the same core analysis functions, so improvements reach both.
In: Rigel's agents call MCP servers you register (for example Slack, GitHub, the bundled read-only Postgres server, or anything else over stdio or HTTP), limited by a per-agent allowlist.

02 · Tool explorer

Twenty tools. All read-only.

Pick a tool to see a sample call. No MCP tool can change your code.

Repo · 7

list_repositories

Which repos are charted?

get_service_info

What is this service, and what do its deep-analysis docs say?

get_dependency_graph

What does this service depend on, and what depends on it?

get_api_surface

Which endpoints exist, by service, method or path?

get_communication_channels

How do services talk: HTTP, queues, event buses, shared databases?

search_context

What does the chart say about this topic in this repo?

semantic_search

Find docs and analysis by meaning (needs a Voyage AI key).

Cross-repo · 2 — endpoints & queues Beta

find_consumers

Who, in any other charted repo, consumes this package, endpoint or queue?

cross_repo_impact

What's the graded cross-repo impact of this change, per repo and service?

Code graph · 7

get_callers

Who calls this function?

get_callees

What does this function call?

get_imports

What does this file import, and who imports it?

get_class_hierarchy

What does this class extend or implement?

get_code_community

Which cluster of code does this belong to?

get_subgraph

Everything within N hops of a symbol.

search_graph

Find a symbol in the graph.

Application · 4

list_products

Which applications (constellations of repos) exist?

get_product_info

Which repos and services make up this application?

search_product_context

Search across every repo in the application.

get_product_assembly

The integration graph and data-flow narratives.

rigel · find_consumers

→ request · tools/call
{
  "method": "tools/call",
  "params": {
    "name": "find_consumers",
    "arguments": {
      "source_repository_id": "orders-api",
      "package_names": ["@your-org/orders-client"]
    }
  }
}

← result · text
Cross-repo consumers for changes in orders-api:
Repos affected: fulfillment, billing
[package] fulfillment / fulfillment-service · severity: warning
  Depends on package "@your-org/orders-client"
[package] billing / billing-worker · severity: warning
  Depends on package "@your-org/orders-client"

Argument names are real. Sample repos and output are illustrative.

03 · What changes

A blind rename, or a safe one.

Same prompt, same agent. The only difference is the chart.

Without Rigel

> Rename customerId to accountId in the Order type of @your-org/orders-client

● Edit · src/order.ts

⎿ tests pass in this repo

⎿ PR merged

● Done. Renamed the field and updated every reference in this repo.

✗ 2 services in other repos break on their next upgrade

Illustration

With Rigel

> Rename customerId to accountId in the Order type of @your-org/orders-client

● rigel · find_consumers(source_repository_id: "orders-api", package_names: ["@your-org/orders-client"])

⎿ fulfillment-service · package · warning

⎿ billing-worker · package · warning

● Two services in other repos still read customerId. I'll add accountId, keep customerId as deprecated, and list both consumers in the PR.

✓ both consumers keep working, and reviewers can see why

Illustration

Package matching reads package.json manifests. Endpoint and queue matching are Beta and depend on how much detail the chart recorded.

04 · MCP in

Rigel's agents use your servers.

Any server, stdio or HTTP

Operators register servers in Settings; agents bind them through their allowlist.

Secrets by reference

Credentials are $VAR references, never pasted into prompts. Spawned servers get a minimal environment.

Per-agent allowlists

Tools = what the agent declares and the operator allows. Edit, Write, Bash, web and sub-agent built-ins are always banned.

Read-only for exposed agents Beta

Agents shared over A2A with MCP access are checked at enable time. Any tool marked readOnlyHint: false blocks the enable.

Binding a tickets server to an A2A agent · Illustration

Tool	Declared by agent	Allowed by operator	Not a banned built-in	readOnlyHint not false	Result
get_issue tickets server	✓	✓	✓	✓	bound
search_issues tickets server	✓	✗	·	·	not offered
Bash built-in	✓	✓	✗	·	always banned
create_issue tickets server	✓	✓	✓	✗	enable blocked

The read-only check is fail-closed: if a server can't be introspected, the agent isn't enabled.

A data boundary for sensitive databases

A bundled, read-only Postgres MCP server lets an agent query a sensitive database without the data leaving the boundary unredacted. Eight layers, in order:

1 · Read-only role

dedicated grants

2 · Row-level security

tenant setting per query

3 · Read-only transactions

every statement

4 · Statement timeout

default 5 s

5 · Row cap

with a truncated signal

6 · SQL validation

table and function allowlists

7 · One statement only

no multi-statements

8 · Default-deny redaction

unlisted columns come back redacted

Plus audit and your part

Errors are sanitised for the agent while the full error goes to an audit log of every query.

Some layers depend on you: the database role, grants and row-level security must be configured, and the redaction policy must be written. See Security & Trust.

05 · Connect

Run it where your agents run.

Prerequisite: at least one repo charted with Rigel, two or more for cross-repo answers.

Local · stdio

Next to your agent

The server runs on the developer machine and connects straight to your Rigel database.

The machine needs network access to that database.
The connection string needs schema-owner rights Today. Treat it as a production credential.

In your cluster · HTTP Beta

One endpoint for the team

Stateless Streamable HTTP at /mcp. Every request gets a fresh server; all state lives in Postgres.

Scales horizontally. GET /health for probes.
No built-in auth: keep it in-cluster or behind your own authenticating proxy.

Hosted · authenticated Coming soon

Remote, with auth

An authenticated, hosted MCP endpoint ships with Rigel Cloud. Until then, run Rigel MCP inside your network.

Recommended · HTTP

Today's pattern: an authenticating proxy. Keep the MCP service cluster-internal. Put an identity-aware reverse proxy (your OIDC provider) in front of /mcp, and give each developer's agent a token from that proxy, not a database credential. The MCP server holds no state, so it scales behind the proxy like any stateless HTTP service. This avoids handing out the schema-owner connection string that stdio needs today.

# terminal
claude mcp add --transport http rigel https://rigel.internal.example/mcp

# ~/.cursor/mcp.json
{ "mcpServers": { "rigel": { "url": "https://rigel.internal.example/mcp" } } }

# .vscode/mcp.json
{ "servers": { "rigel": { "type": "http", "url": "https://rigel.internal.example/mcp" } } }

# any MCP client · command name for the upcoming release
{
  "mcpServers": {
    "rigel": {
      "command": "rigel-mcp",
      "env": {
        "DATABASE_URL": "<YOUR_DATABASE_URL>",
        "VOYAGE_API_KEY": "<YOUR_VOYAGE_API_KEY>"
      }
    }
  }
}

The URL is a placeholder for your in-network host. VOYAGE_API_KEY powers semantic_search; without it, that tool reports it's unavailable and the other 19 still work.

Next in the platform →

Rigel Map: how the chart is built from your repos.

What ships today →

Every capability, with its status.

Book a technical walkthrough →

We'll connect an agent to a charted repo with you.

Your first `find_consumers`, once your repos are charted.

Bring the agent you already use. Rigel is the control plane above it, not another one to switch to.

Get early access How Rigel builds the chart →

MCP quickstart: Docs (soon).