> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chargerdojo.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Connect a coding agent
> Point Claude Code, Codex, Cursor or any MCP client at ChargerDojo's hosted server, so your agent can answer OCPI questions and read your test runs.
ChargerDojo runs a server that coding agents can call directly, at
`https://chargerdojo.com/api/mcp`. It speaks the
[Model Context Protocol](https://modelcontextprotocol.io), the standard your agent
already uses to reach tools outside itself.
Connect it and you can ask OCPI questions in the editor you are already in: which
versions exist, how each one encodes the credentials token, what changed between
2.2.1 and 2.3.0, which suites and journeys you can run. **That half needs no
account, no key and no signup.** Answers come from the same registry the simulator
obeys, so they match what the site does rather than what a model remembers.
Add your `cdojo_` API key and the same agent also reads your account: your
registered endpoints, your run history, a verdict, your remaining quota.
## Connect it
Each of these was run against the live endpoint.
```bash Claude Code theme={null}
claude mcp add --transport http chargerdojo https://chargerdojo.com/api/mcp
```
```bash Codex theme={null}
codex mcp add chargerdojo --url https://chargerdojo.com/api/mcp
```
```json Cursor theme={null}
{ "mcpServers": { "chargerdojo": { "url": "https://chargerdojo.com/api/mcp" } } }
```
```json opencode theme={null}
{ "mcp": { "chargerdojo": { "type": "remote", "url": "https://chargerdojo.com/api/mcp", "enabled": true } } }
```
Cursor reads `~/.cursor/mcp.json`; opencode reads `~/.config/opencode/opencode.json`.
Any other client that speaks Streamable HTTP takes the URL and nothing else.
opencode's own published examples show `mcp.servers.`. That shape does not
connect. The one above does.
## Ask it something
Nothing else to set up. Ask your agent a version question and it will reach for
the server:
> What changed between OCPI 2.2.1 and 2.3.0?
```text theme={null}
None of the transport and structure rules tracked here changed between these versions.
Those rules are the credentials token encoding, the sender and receiver split, the
CdrToken party fields, and the Locations enums. They are not a full diff of the two
specifications, so treat this as a starting point rather than a complete list.
Modules ChargerDojo implements at 2.3.0 but not at 2.2.1: booking.
That is this simulator gaining coverage, which is not the same claim as the spec
gaining a module.
```
That last line is the habit worth noticing. The server separates what the
specification says from what ChargerDojo implements, every time, because
conflating the two is how an integrator ends up planning against a module nobody
has. `chargerdojo_describe_access` will tell you at any point which tools your
connection currently has.
## Add your key
Six tools are open to anyone. The other eight read or act on one account, so they
need an API key, the same `cdojo_` key the [REST API](/api) uses. Send it as a
bearer token:
```bash theme={null}
claude mcp remove chargerdojo
claude mcp add --transport http chargerdojo https://chargerdojo.com/api/mcp \
--header "Authorization: Bearer $DOJO_KEY"
```
The remove is not optional if you already ran the command above. The name is the
identity, so a second `add` says `MCP server chargerdojo already exists` and
changes nothing: your header never lands, and the account tools never appear.
Clients that take a config file instead carry the same header in a `headers` map
beside the URL.
Keys are created in the app, under **Settings**, then **Security**, and need a paid
plan. See [Create an API key](/guide/create-an-api-key).
A key is the whole account. There are no per-tool scopes: an agent holding your
key reads every target and every report the account owns, and can spend its
quota. Give an agent a key you are willing to revoke.
Runs an agent starts are recorded in your account's audit log as agent-started,
naming the tool, so a shared account can still tell who did what.
## Every tool
**Open to anyone, no account:**
| Tool | Arguments | Answers |
| ------------------------------------- | -------------------- | ------------------------------------------------------------------------------- |
| `chargerdojo_describe_access` | none | What this server can do, and which tools your connection currently has. |
| `chargerdojo_list_ocpi_versions` | none | The OCPI versions covered, and which modules each implements. |
| `chargerdojo_get_ocpi_version` | `version` | One version in detail: token encoding, sender and receiver split, known limits. |
| `chargerdojo_compare_ocpi_versions` | `from`, `to` | What changed between two versions, and which modules ChargerDojo gained. |
| `chargerdojo_list_conformance_suites` | `version` (optional) | The suites you can run, by module, with check counts. |
| `chargerdojo_list_journey_templates` | none | The charging journeys runnable against the built-in sandbox. |
**With an API key:**
| Tool | Arguments | Does |
| ------------------------------------ | ------------------------------ | --------------------------------------------------------------- |
| `chargerdojo_list_targets` | none | Lists the OCPI endpoints registered on the account. |
| `chargerdojo_list_runnable_journeys` | `targetId` | Says which journeys one target supports, and why. |
| `chargerdojo_run_sandbox_journey` | `templateId` (optional) | Runs a journey against the sandbox and returns the verdict. |
| `chargerdojo_list_runs` | none | Recent runs and journeys, with status and pass and fail counts. |
| `chargerdojo_get_run_verdict` | `reportId` | One run's verdict, including whether anything graded at all. |
| `chargerdojo_get_journey_events` | `reportId`, `after` (optional) | Step by step, what happened and which assertions passed. |
| `chargerdojo_cancel_run` | `reportId` | Stops a running journey at the next safe point. |
| `chargerdojo_get_usage` | none | The plan and how much of each ceiling is left. |
The ids chain: `list_targets` gives you a `targetId`, and every run tool takes the
`reportId` that `list_runs` or `run_sandbox_journey` hands back. You should not have
to look any of this up, though. Ask your agent to list the server's tools and it
gets the current names, descriptions and argument schemas, which stay right when
this table drifts.
## What it will not do
**It does not start conformance runs against your partner.** A suite run costs
minutes and quota, and an agent that starts one on a hunch is expensive in a way
you find out about later. Start those through the [REST API](/api), where the call
sits in your script and you can see it. `chargerdojo_run_sandbox_journey` is the
exception, because the sandbox is ours and a wasted run costs you nothing but your
own rate limit.
**An agent gets half your rate, not all of it.** Tools that start work draw on half
your plan's runs per minute and half its in-flight cap, so a looping agent leaves
your CI pipeline the other half.
## If your agent cannot connect
* The URL is `https://chargerdojo.com/api/mcp`, with no trailing slash and no
version segment. `docs.chargerdojo.com` runs a different server, for these pages.
* A client on an older MCP revision still works. The endpoint answers both the
current revision and the 2025 ones from the same URL.
* If the account tools are missing, the key did not arrive. The usual cause is the
one above, a second `add` refused because the name was taken. Otherwise check the
header reached the server rather than that it sits in the config file: some
clients send only the headers they were given at add time.
* A revoked or unknown key gets a `401` and the message `Invalid or revoked API
key`. It never quietly drops you to the open six, because running an agent
against the wrong account is worse than an error.
* The server is listed in the official MCP registry as `com.chargerdojo/ocpi`, if
your client discovers servers that way.