@odatano/nightgate-mcp
Official<p align="center">
<picture>
<source media="(prefers-color-scheme: dark)" srcset="https://cdn.jsdelivr.net/npm/@odatano/brand@1/logos/nightgate-mcp-logo.svg">
<img src="https://cdn.jsdelivr.net/npm/@odatano/brand@1/logos/nightgate-mcp-logo-on-light.svg" alt="NIGHTGATE MCP" height="84">
</picture>
</p>
# @odatano/nightgate-mcp
[](https://www.npmjs.com/package/@odatano/nightgate-mcp)
[](https://www.npmjs.com/package/@odatano/nightgate)
[](https://modelcontextprotocol.io/)
[](LICENSE)
MCP server for [NIGHTGATE](https://github.com/ODATANO/NIGHTGATE) on Midnight.
Anchors documents, proves zero-knowledge claims over hidden fields, grants
disclosure, and verifies records and claims against live contract state;
swaps shielded tokens over an offer board and mints them on a token factory.
Transactions are sponsored, the agent holds no NIGHT. The chain is read through the
[ODATANO API](https://api.odatano.dev), and the wallet syncs its coins through
the gateway's indexer lane: no indexer, no node.
## Quick start
Get an `oda_…` key at [api.odatano.dev](https://api.odatano.dev) (Cardano
wallet sign-in, a redeem code, or tADA over x402), then:
```json
{
"mcpServers": {
"nightgate": {
"command": "npx",
"args": ["-y", "@odatano/nightgate-mcp"],
"env": { "ODATANO_ACCESS_KEY": "oda_..." }
}
}
}
```
Claude Code: `claude mcp add nightgate --env ODATANO_ACCESS_KEY=oda_... -- npx -y @odatano/nightgate-mcp`
The hosted gateway is the default (Midnight preprod). The same key works for
`@odatano/core-mcp` (Cardano). Node.js >= 20.
That is all the setup. `anchor_document` with the sha256 of a document anchors
it in the shared sandbox vault and answers once it landed, with the free
`verify_attestation` call that shows it on-chain. The first write creates your
seed in `~/.nightgate-mcp/seed` and says so; keep that file, it is your
identity on Midnight. Servers on one machine share it unless each sets its
own `NIGHTGATE_SEED_HEX`. `get_usage` shows the units left on the key.
## Tools
[docs/tools.md](docs/tools.md) lists every tool, what a write returns, the
sandbox vaults, the seed, field claims and shielded swaps. Every write is
built and proven here, a sponsor pays, and the tool waits for the result.
Errors carry the server's HTTP status and `code`.
## Configuration
[docs/configuration.md](docs/configuration.md): every variable, an own
NIGHTGATE instance, version requirements. Needs NIGHTGATE >= 0.36.0; from 0.37.0
the server holds each status read until the job settles; from 0.38.0
`list_swap_offers` and `my_swap_offers` wait with `waitMs`; from 0.39.0
`send_token`, `burn_token`, directed offers and receipts; from 0.40.0 sponsored
payouts from a contract. `get_board_status` names the version a server runs.
## Development
```bash
npm install && npm run test:unit && npm run integration
```
Live lanes:
```bash
NIGHTGATE_LIVE=1 NIGHTGATE_TEST_CONTRACT=<vault> NIGHTGATE_TEST_PAYLOAD_HASH=<64 hex> npm run integration
NIGHTGATE_SEED_HEX=<hex> NIGHTGATE_VAULT=<vault> npm run live:sponsor-unbound
```
## License
Apache-2.0
TDQS
Scored across 28 tools
The set covers several broad domains and most tools have distinct purposes, but there is meaningful overlap between board/offer reading tools (get_swap_offer vs read_swap_offer), swap lifecycle tools, and transaction-building/submitting/sponsoring variants. The very long descriptions help, but an agent can still hesitate between submit_vault_call, build_sponsorable_transaction, call_contract, and anchor_document for related attestation/contract work.
Most tool names follow a predictable snake_case verb_noun pattern such as get_swap_wallet, build_swap_offer, post_swap_offer, verify_attestation, and prepare_document_proof. Minor deviations like my_swap_offers and read_swap_offer are readable but slightly break the pattern.
The server genuinely spans attestation, ZK predicates, shielded swaps, token minting/burning/transfers, sponsoring, and contract calls, so many tools are justified. However, 28 tools is heavy, and the ten or so swap-related tools plus multiple sponsoring/build abstractions make the surface feel larger than necessary.
Coverage is strong: swaps have build/read/post/list/get/take/sponsor/retire/revert lifecycle tools, attestation has prepare/anchor/verify/prove operations, and token and sponsoring flows are well represented. Minor gaps include no obvious way to list or enumerate all attestations and no generic job-status/query tool beyond result payloads.