> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/de/produkte/rome-cli.md).

# Rome CLI + MCP

`rome` führt einen Builder — einen Menschen oder einen KI-Agenten — durch den gesamten Build-on-Rome-Lebenszyklus: fundierte Chain-Fakten, das richtige Muster, Contract-Aufrufe, die Funding-On-Ramp, Deploy/Send, kettenübergreifende Diagnose und ein Works-Gate für beide Lanes. Ein Kern für alle Fähigkeiten, zwei abgestimmte Oberflächen — eine CLI (`rome <command>`) und einen [MCP](https://modelcontextprotocol.io) -Server (`rome mcp`) — damit Agent und Mensch dasselbe mentale Modell teilen.

## Installieren

Repo-first (npm-Publishing steht noch aus):

```bash
# Einmalig, keine Installation:
npx github:rome-protocol/rome-cli facts chain hadrian

# Dauerhafte Installation — klonen + verlinken:
git clone https://github.com/rome-protocol/rome-cli
cd rome-cli && npm install && npm install -g .
```

Ein einfaches `npm install -g github:rome-protocol/rome-cli` funktioniert **nicht** heute — npm bereitet die Git-Abhängigkeiten des Pakets ohne deren eigenes node\_modules vor ([rome-cli#25](https://github.com/rome-protocol/rome-cli/issues/25)). Nutze die npx-Einmalausführung oder clone + link. Pinne ein Tag (`github:rome-protocol/rome-cli#v0.8.0`), wenn du reproduzierbare Läufe brauchst.

## Zwei Ebenen über einem Kern

**Lesen — Grounding + Diagnose.** Keine Keys; sowohl auf der CLI als auch auf dem MCP-Server.

| Befehl                                                   | Was es zurückgibt                                                                                                                              |
| -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `rome facts chain·tokens·contracts·gas·balance·programs` | aktuelle Chain-Fakten aus Registry + RPC — keine halluzinierten IDs, Adressen oder Selektoren                                                  |
| `rome cookbook patterns·cpi-recipe·errors`               | welches Beispiel zu deinem Ziel passt · die CPI-Account-Regeln, bei denen Agenten falsch liegen · einen Rome-Fehler dekodieren → Ursache + Fix |
| `rome call <chain> <addr> <sig> [args]`                  | einen Contract lesen (`eth_call`) — Mehrwert-Argumente werden durch Kommas in einem Argument getrennt: `"0xOwner…,0xSpender…"`                 |
| `rome doctor <chain>`                                    | Vorabcheck — Chain live? RPC erreichbar? Programm konfiguriert? Wallet finanziert?                                                             |
| `rome tx <chain> <hash>`                                 | eine Transaktion diagnostizieren — EVM-Receipt + die Solana-Abwicklungs-Transaktion(en) + ein Via-Link (Rome hat kein `debug_trace*`)          |
| `rome preset foundry\|hardhat <chain>`                   | eine fertige Rome-Netzwerkkonfiguration für dein Toolchain + die Eigenheiten                                                                   |

**Aktionen — on-chain signieren.** nur CLI, Schlüssel aus der Umgebung, **niemals** auf MCP.

| Befehl                                                                     | Was es tut                                                                                                                                                                                                                                                                                                                                      |
| -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `rome deploy <chain> <artifact>`                                           | einen kompilierten Contract deployen und dabei Roms Gas-Eigenheiten handhaben                                                                                                                                                                                                                                                                   |
| `rome send <chain> <addr> <sig>`                                           | über den korrekten Rome-Write-Pfad in einen Contract schreiben                                                                                                                                                                                                                                                                                  |
| `rome fund <chain> --from <src> --amount <usdc>`                           | USDC → Rome-Gas (CCTP) bridgen — die On-Ramp „von zu Hause“                                                                                                                                                                                                                                                                                     |
| `rome bridge <chain> --from <src> --amount <usdc> [--intent gas\|wrapper]` | USDC bridgen **in** als Gas oder wUSDC                                                                                                                                                                                                                                                                                                          |
| `rome bridge <chain> --to <dest> --amount <usdc>`                          | wUSDC bridgen **aus** — auf Rome verbrannt; du beanspruchst auf dem Zielnetzwerk (Rome subventioniert den Inbound, nicht den Outbound-Claim)                                                                                                                                                                                                    |
| `rome activate <chain>`                                                    | einmalige PDA-Finanzierung erforderlich vor dem **ersten Bridge-Out** (Inbound ist reibungslos — benötigt nichts)                                                                                                                                                                                                                               |
| `rome verify <chain> [--path …]`                                           | das **pfadbewusste Works-Gate**, je eines pro Eintrittsweg: `solidity` — dasselbe Contract antwortet auf der EVM-Lane *und* der Solana-Lane · `solana-program` — ein Aufruf auf der EVM-Lane steuert dein Solana-Programm per CPI an · `von zu Hause` — hinein bridgen → auf Rome handeln → hinaus bridgen, die Hin- und Rückreise ist bewiesen |

## In einen KI-Agenten einbinden (MCP)

Du musst nichts ausführen oder hosten — dein MCP-Client startet `rome mcp` (einen stdio-Server) bei Bedarf. Einmal registrieren:

```json
{ "mcpServers": { "rome": { "command": "npx", "args": ["-y", "github:rome-protocol/rome-cli", "mcp"] } } }
```

(Mit der Installation per clone + link funktioniert `{ "command": "rome", "args": ["mcp"] }` auch — die npx-Form braucht nur keine vorherige Installation.)

Dann ruft der Agent Tools wie `facts_chain`, `cookbook_cpi_recipe`, `doctor`, `tx`, und `preset` auf — fundiert durch das Live-Registry + RPC, sodass es aufhört, Adressen und Selektoren zu raten. Die MCP-Oberfläche ist **nur lesend und hält keine Keys** — sicher für jede Agenten-Einbindung; sie kann niemals signieren oder Gelder bewegen. Die Signier-Aktionen bleiben auf der CLI, wobei der Schlüssel über die Umgebung bereitgestellt wird.

## Die Grounding-Schleife des Agents

1. `rome cookbook patterns <was ich baue>` → welches Beispiel-Repo + welche Architektur
2. `rome facts chain <chain>` → RPC, Programm-ID, Gas-Token (kein Hardcoding)
3. …Code gegen genau diese Werte schreiben…
4. `rome verify <chain> --path <dein Eintrittsweg>` → beweisen, dass es funktioniert, egal welchen Weg du genommen hast

## Mehr erfahren

* Repo + vollständige Anleitungen: [`rome-protocol/rome-cli`](https://github.com/rome-protocol/rome-cli)
* [Ökosystem & Repos](/de/erste-schritte/ecosystem.md) · [Eine Dual-Lane-App bauen](/de/entwicklerleitfaden/dual-lane-app.md) · [Von zu Hause: Rome von einer anderen Chain aus erreichen](/de/entwicklerleitfaden/from-home.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/de/produkte/rome-cli.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.