Content
# naba
A standalone CLI (a single Rust binary) for AI image generation with multiple
providers — **Google Gemini**, **OpenRouter**, and **AWS Bedrock**. Generate, edit, and
transform images from the command line.
**Website:** [naba.ysapp.net](https://naba.ysapp.net) — docs, usage examples with sample
output, and a one-line bootstrap install.
## Install
`naba` is a single self-contained binary — no runtime, no dependencies.
### Vendor Install (from `naba.ysapp.net`)
The site hosts `install.sh` — so the first install is just:
```bash
curl --proto '=https' --tlsv1.2 -LsSf https://naba.ysapp.net/install.sh | sh
```
GitHub Releases remains canonical for every binary.
### Homebrew (macOS and Linux)
If you already live in Homebrew, the you can use the tap — but a Homebrew install does **not**
self-update via `naba self update`; upgrades come through `brew upgrade`:
```bash
brew install dixson3/tap/naba
brew upgrade naba # update later
```
### Cargo
```bash
cargo install --git https://github.com/dixson3/naba
```
### Build from source
```bash
git clone https://github.com/dixson3/naba.git
cd naba
cargo build --release # binary at target/release/naba
# Optionally put this build on your PATH as a "from-build" install (~/.local/bin):
./target/release/naba self install --from-build
```
## Self-update
`naba self` manages the binary itself. It only auto-updates a **vendor** install (the
`curl | sh` installer above); Homebrew installs are refused with a pointer to `brew upgrade
naba`, and a from-build/unknown install needs `--force`.
```bash
naba self update # fetch the latest release, verify sha256, swap in place
naba self update --check # report whether an update is available; change nothing
naba self update --json # machine-readable envelope (status/source/current/latest)
naba self install --from-build # record the running build as a from-build install
naba self uninstall # remove the from-build marker (--force also deletes the binary)
```
A successful `self update` also refreshes the installed harness skills (`naba skills
upgrade`) unless you pass `--binary-only`. `version` and `doctor` print a throttled, offline
"update available" nudge for vendor installs.
You can set `NABA_NO_UPDATE_CHECK=1` (or run in `CI`) to silence it.
## Setup
Set the API key for whichever provider(s) you use:
```bash
export GEMINI_API_KEY=<your-key> # Google Gemini
export OPENROUTER_API_KEY=<your-key> # OpenRouter
export AWS_BEARER_TOKEN_BEDROCK=<your-token> # AWS Bedrock (api-key bearer path)
```
You can also save a key per provider into config (stored inline in `config.yaml`):
```bash
naba config set gemini.api-key <your-key>
naba config set openrouter.api-key <your-key>
naba config set bedrock.api-key <your-token>
```
**API-key resolution** is uniform for every provider — highest precedence first: inline
`providers.<provider>.api-key` takes precedence over the env var named by `providers.<provider>.api-key-envvar` which in turn takes precedence over
the provider's conventional env var (`GEMINI_API_KEY` / `OPENROUTER_API_KEY` /
`AWS_BEARER_TOKEN_BEDROCK`).
See [Providers](#providers) for how `naba` picks a provider when one or more keys are present.
## Providers
`naba` routes every image command (`generate`, `edit`, `restore`, and the composites)
through one of its registered providers:
| Provider | Conventional key env var | Default model | Endpoint |
|:---------|:-------------------------|:--------------|:---------|
| `gemini` | `GEMINI_API_KEY` | `gemini-3.1-flash-image` | `{base}/models/{model}:generateContent` |
| `openrouter` | `OPENROUTER_API_KEY` | `google/gemini-3.1-flash-image-preview` | `POST /api/v1/images` |
| `bedrock` | `AWS_BEARER_TOKEN_BEDROCK` | `amazon.nova-canvas-v1:0` | `POST {base}/model/{modelId}/invoke` |
Discover providers and models from the CLI:
```bash
naba provider # list providers + credential status (* marks the default)
naba provider --json # machine-readable {status, data} envelope
naba models --provider bedrock # list a provider's models (needs a resolvable key)
```
Select the provider with the global `--provider` flag or the `default-provider` config key:
```bash
naba generate "a red apple" --provider gemini
naba generate "a red apple" --provider bedrock
naba config set default-provider gemini # pin a default provider
```
### Provider resolution precedence
When you don't pass `--provider`, `naba` resolves the provider in this order:
1. **CLI** `--provider`
2. **Config** `default-provider` key
3. **Env-key autodetect** — among providers with resolvable credentials, the one **latest** in
the registry order (`gemini` → `openrouter` → `bedrock`) wins
4. **Built-in fallback** — gemini (the missing-key error surfaces at call time)
### Multi-key reroute (intentional behavior)
Autodetect scans the registry order and the **latest** provider with credentials wins. So if
both `GEMINI_API_KEY` and `OPENROUTER_API_KEY` are set **and** no `default-provider` is
configured, autodetect resolves to **OpenRouter**; add Bedrock credentials and it reroutes to
**Bedrock**. This is an intentional precedence outcome, not a bug.
> **To stay put when several keys are set, pin the provider in config** — config beats
> autodetect:
>
> ```bash
> naba config set default-provider gemini
> ```
### AWS Bedrock auth
Bedrock supports **both** an api-key bearer token (`AWS_BEARER_TOKEN_BEDROCK` /
`bedrock.api-key`, sent as `Authorization: Bearer`) **and** the AWS profile / SigV4 path
(`AWS_ACCESS_KEY_ID` + `AWS_SECRET_ACCESS_KEY` [+ `AWS_SESSION_TOKEN`], or a named `AWS_PROFILE`
in `~/.aws/credentials`).
`naba` prefers the bearer token when one resolves, else signs with
SigV4. The region defaults to `us-east-1`, resolved in this order (highest precedence first):
1. `AWS_REGION`
2. `AWS_DEFAULT_REGION`
3. the built-in default (`us-east-1`)
### `--model` requires `--provider`
A bare `--model` on the CLI is ambiguous across providers, so `--model` **without**
`--provider` is a usage error (exit 2).
Always pair them:
```bash
naba generate "hero" --provider openrouter --model google/gemini-3.1-flash-image-preview
```
This rule is **CLI-flags-only**: a config `model` **without** a config `provider` is fine —
the config model is scoped by whatever provider autodetect/config resolves.
## Models & pricing
**Gemini** defaults to **`gemini-3.1-flash-image`** (Nano Banana 2) — the current GA image
model, optimized for cost and latency. A higher-quality tier, **`gemini-3-pro-image`**
(Nano Banana Pro), is available for final/hero assets.
> **All Gemini image models require a paid (billing-enabled) tier — none work on the free
> tier.** Pro costs roughly 2–3.5× flash per image, so flash is the default; opt into pro
> only when you need its quality.
Select the model per call or in config:
```bash
naba generate "hero banner" --quality high # alias: high -> gemini-3-pro-image
naba generate "hero banner" --quality fast # alias: fast -> gemini-3.1-flash-image (default)
naba generate "hero banner" --provider gemini --model gemini-3-pro-image # raw model id (highest precedence)
```
For Gemini, the model is resolved in this order (highest precedence first):
1. `--model` (CLI flag)
2. `--quality` (CLI flag)
3. config `model`
4. config `quality`
5. the built-in default
Existing configs (e.g. `model: gemini-2.5-flash-image`) keep working unchanged.
### `--quality` semantics differ per provider
The `fast`/`high` vocabulary is the cross-provider surface, but each provider interprets it
differently:
- **Gemini** — `--quality` selects a **model tier**: `fast` → `gemini-3.1-flash-image`,
`high` → `gemini-3-pro-image`. Any other value is a usage error. An explicit `--model`
overrides `--quality`.
- **OpenRouter / Bedrock** — `--quality` is passed through as a **native request parameter**;
it does **not** swap the model. The model is chosen independently (`--model` / config
`<provider>.model` / the default). So `--provider openrouter --quality high` keeps the
resolved slug and sends `quality: high`.
`openrouter/auto` (and bare `auto`) is a text-only router and **cannot** generate images —
`naba` rejects it early with a usage error.
## Usage
### Generate images
```bash
naba generate "a red apple on a white background"
naba generate "mountain landscape" --style watercolor
naba generate "city skyline" -n 4 --style pixel-art
naba generate "abstract art" -v lighting -v color-palette -o art.png
naba generate "wide vista" --aspect 16:9 --resolution 2K
```
**Aspect ratio & resolution.** `--aspect` and `--resolution` set the Gemini
`imageConfig` and are available on all generative commands (`generate`, `edit`, `restore`,
`pattern`, `diagram`, `story`). Valid `--aspect`: `1:1, 1:4, 1:8, 2:3, 3:2, 3:4, 4:1, 4:3,
4:5, 5:4, 8:1, 9:16, 16:9, 21:9`. Valid `--resolution`: `512, 1K, 2K, 4K` (uppercase `K`).
Invalid values are rejected before the API call. `icon --size` is **canvas pixels** — a
separate concept from `imageConfig`'s `imageSize` — and is unchanged.
### Edit images
```bash
naba edit photo.png "make the sky more dramatic"
naba edit portrait.jpg "add a hat" -o portrait-hat.png
```
### Restore/enhance images
```bash
naba restore old-photo.jpg
naba restore blurry.png "sharpen and improve colors"
```
### Generate icons
```bash
naba icon "a music note" --size 64 --size 256 --size 512
naba icon "rocket ship" --style flat --background white --corners sharp
```
### Generate patterns
```bash
naba pattern "tropical leaves" --style floral --colors colorful
naba pattern "circuit board" --style tech --density dense --colors mono
```
### Generate stories
```bash
naba story "a cat's journey through a magical forest" --steps 6
naba story "sunrise to sunset" --steps 4 --transition dramatic
```
### Generate diagrams
```bash
naba diagram "user authentication flow" --type flowchart
naba diagram "microservices architecture" --type architecture --complexity comprehensive
naba diagram "database schema for blog" --type database --style clean
```
### Configuration
The config is **nested and per-provider**: a `default_provider`, a `providers` map (each entry
`{model, api-key?, api-key-envvar?}`), and top-level image defaults.
```bash
naba config set default-provider gemini # default provider (gemini, openrouter, bedrock)
naba config set gemini.api-key <key> # a provider's inline api-key
naba config set gemini.model gemini-3-pro-image # a provider's default model (or: config set quality high)
naba config set gemini.api-key-envvar MY_KEY # a provider's custom key env var
naba config set aspect 16:9 # default imageConfig aspect ratio
naba config set resolution 2K # default imageConfig resolution
naba config get gemini.model
naba config get gemini.model --json # machine-readable envelope
```
Config keys: `default-provider`, `<provider>.model`, `<provider>.api-key`,
`<provider>.api-key-envvar` (provider ∈ `gemini`, `openrouter`, `bedrock`),
`default_output_dir`, `aspect`, `resolution`, `quality`. Per-call flags override config; within
config, a provider's `model` beats `quality`, and `default-provider` beats env-key autodetect
(see [Providers](#providers)). The legacy flat keys `api_key` (→ `gemini.api-key`), `model`
(→ the default provider's model), and `provider` (→ `default-provider`) are still accepted as
aliases.
A full `config.yaml`:
```yaml
default_provider: gemini
providers:
gemini:
model: gemini-3-pro-image
api-key: <inline-key>
openrouter:
api-key-envvar: MY_OR_KEY
bedrock:
model: amazon.nova-canvas-v1:0
aspect: "16:9"
resolution: 2K
```
**Config auto-migration.** An old **flat** config (top-level `api_key` / `model` / `provider`)
is auto-migrated to the nested schema on first load: `naba` writes a `config.yaml.bak` backup
with the original bytes first, then rewrites the document (`api_key` → `providers.gemini.api-key`,
`model` → the default provider's block, `provider` → `default_provider`). It is idempotent and
graceful on empty/missing/malformed inputs; a structural rewrite drops YAML comments (mitigated
by the `.bak` backup).
### MCP Server
`naba mcp` starts a stdio-based [Model Context Protocol](https://modelcontextprotocol.io) server that exposes all 8 image tools to AI assistants like Claude Desktop and Cursor, plus MCP-authored usage guidance for those tools as lazily-loaded `skill://` resources.
MCP is how you give a **desktop** assistant — one that can't run shell commands — first-class access to `naba`: it calls `naba`'s tools directly over the protocol and gets structured results back, no terminal involved. It's the counterpart to [Agent Skills](#agent-skills) above (which shell out to the CLI for coding agents that *do* have a shell); both drive the identical provider/selector/output pipeline, so you get the same images either way — the difference is purely how the assistant reaches `naba`.
**Claude Desktop configuration** — add to your `claude_desktop_config.json`:
```json
{
"mcpServers": {
"naba": {
"command": "naba",
"args": ["mcp"],
"env": {
"GEMINI_API_KEY": "<your-key>",
"OPENROUTER_API_KEY": "<your-key>",
"AWS_BEARER_TOKEN_BEDROCK": "<your-token>",
"NABA_OUTPUT_DIR": "/path/to/output"
}
}
}
}
```
Setting `NABA_OUTPUT_DIR` is recommended — it tells `naba` where to write generated images. Without it, images are saved to `~/.local/share/naba/images` by default.
**Available tools:**
| Tool | Description |
|:-----|:------------|
| `generate_image` | Generate an image from a text prompt |
| `edit_image` | Edit an existing image based on a text prompt |
| `restore_image` | Restore or enhance an existing image |
| `generate_icon` | Generate app icons in multiple sizes |
| `generate_pattern` | Generate seamless patterns and textures |
| `generate_story` | Generate a sequence of images that tell a visual story |
| `generate_diagram` | Generate technical diagrams and flowcharts |
| `list_images` | List recently generated images in the output directory |
The generative tools accept `aspect`, `resolution`, and `quality` params (matching the
CLI); `generate_icon` accepts `quality`. With `count`/`steps`/`sizes` > 1 the same
`imageConfig` applies to every image in the call.
**Skills as resources (lazy loading).** The server also exposes **MCP-authored** usage guidance
for its tools as `skill://` resources — written for the MCP tools (tool names, params,
`NABA_OUTPUT_DIR`, `file://` results), not the `/naba` CLI docs. `resources/list` enumerates it
cheaply as `skill://naba/<rel>` URIs (paths only — no bodies) plus a compact `skill://naba` index;
`resources/read` serves a file's content on demand (`skill://naba/<rel>`) or the generated index
(`skill://naba`). Each generation tool's description points to `skill://naba`. See the website
[MCP page](https://naba.ysapp.net/mcp/).
**Manual test** — verify the server responds to the MCP initialize handshake:
```bash
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0.1.0"}}}' | naba mcp
```
## Agent Skills
A **skill** teaches an AI coding agent a new capability — a little instruction plus a command the
agent runs on your behalf. `naba`'s skill turns *"make me an app icon of a rocket ship"* into the
right `naba` invocation, so you get `naba`'s images without leaving the conversation or memorizing
CLI flags.
`naba` ships a **single** skill that wraps the whole CLI as one slash command with subcommands:
`/naba <subcommand>` (e.g. `/naba generate`, `/naba edit`, `/naba icon`, …). It installs into
whichever **agent harness** you use — [Claude Code](https://claude.com/claude-code) is the default
and the running example here, but opencode, pi, codex, and a portable `agents` layout work too
(see [Harnesses](#harnesses) below). The skill files are **embedded in the `naba` binary** at
compile time and installed with `naba skills install`, so installation is offline and always
version-matched — there is no marketplace plugin and no separate installer script.
> **Prefer a desktop assistant that can't run shell commands** (Claude Desktop, Cursor)? Use the
> [MCP Server](#mcp-server) instead — it exposes the same image pipeline over a protocol, so the
> assistant calls `naba`'s tools without a terminal.
> **Prerequisite:** the skill shells out to the `naba` CLI, so the **`naba` binary must be
> installed and on PATH** (see [Install](#install)) and a provider API key set —
> `GEMINI_API_KEY`, `OPENROUTER_API_KEY`, and/or `AWS_BEARER_TOKEN_BEDROCK` (see [Setup](#setup) and
> [Providers](#providers)). `naba skills install` always writes the skill files; the skill is
> inert until the binary is on PATH.
> **Breaking change (plan-002 → plan-003):** the previous 10 separate skills
> (`/naba-generate`, `/naba-edit`, …) were consolidated into one `/naba <subcommand>` skill,
> and the old shell/python installer scripts were replaced by `naba skills`. Those old
> per-command skills are **not** embedded in the binary, so `naba skills` cannot remove
> them. If you installed them under a prior version, delete them manually first:
>
> ```bash
> rm -rf ~/.claude/skills/naba-* # user/claude scope; adjust path for --surface agents or project scope
> ```
>
> Then install the consolidated skill with `naba skills install`.
> **Upgrading from the Go build (post-cutover):** `naba` is now a single **Rust** binary
> (plan-004). The embedded skill content changed in the cutover, so the integrity hash the
> binary computes differs from the one written by any previously installed (Go-built) `naba`.
> After installing the Rust binary, run **`naba skills upgrade`** once to rewrite the
> installed skill tree from the new embedded content:
>
> ```bash
> naba skills upgrade
> ```
>
> Until you do, `naba skills status` and `naba doctor` will report the installed copy as
> **outdated** (`installed copy is outdated vs this binary (run: naba skills upgrade)`) —
> that guidance is surfaced automatically, so no action is needed beyond running the upgrade.
> The refreshed embedded tree hashes to
> `d5b2fdfe452b2d803670dd781cbf92375f1600ddac6220831cec6aae7fe368c8`.
### Install the skill
```bash
naba skills install # default: claude-code harness, user scope -> ~/.claude/skills
naba skills install --dry-run # show what would be written, change nothing
naba skills install --scope project # install into <git-root>/.claude/skills instead
naba skills install --harness opencode # install into ~/.config/opencode/skills
naba skills install --harness claude-code --harness pi # repeatable: several harnesses at once
naba skills install --target DIR # install into an explicit directory
naba skills upgrade # refresh every previously-installed harness target
naba skills remove # remove the naba skill again
naba skills status # report up-to-date / complete / unmodified
```
The skill tree is embedded into the binary at compile time, so `naba skills` works offline and always
matches the binary's version. On `install`/`upgrade` it writes a hidden integrity marker
into the deployed `SKILL.md` (`<!-- naba-skills: v=<version> tree=<sha256> -->`); `status`
and `naba doctor` use that marker to confirm the install is current, complete, and
unmodified. The repository source `skills/naba/SKILL.md` stays marker-free. Every verb also
accepts `--json` for a machine-readable `{status, data}` envelope.
### Harnesses
The same embedded skill tree installs to several agent **harnesses**, each at its own idiomatic
skills path. Select one with `--harness <name>`; the flag is **repeatable**, so one `install` can
target several at once:
| Harness | Project-scope path | User-scope path |
|:--------|:-------------------|:----------------|
| **claude-code** (default) | `<root>/.claude/skills` | `~/.claude/skills` |
| **opencode** | `<root>/.opencode/skills` | `~/.config/opencode/skills` |
| **pi** | `<root>/.pi/skills` | `~/.pi/agent/skills` |
| **codex** | `<root>/.agents/skills` | `~/.agents/skills` |
| **agents** (portable) | `<root>/.agents/skills` | `~/.agents/skills` |
The portable **`agents`** harness writes the generic `.agents/skills` location that opencode, pi,
and codex all read — the one-shot way to cover multiple generic harnesses. `--scope` chooses the
`<root>` each harness installs under (**user** = `$HOME`, the default; **project** = the git root,
else the current directory); `--target DIR` overrides scope and harness entirely. `naba skills
upgrade` refreshes **every** harness target you previously installed to (tracked in an install
receipt), continuing on error — so a multi-harness install stays in sync in one call.
> The old `--surface claude|agents` flag still works as a deprecated hidden alias
> (`claude` → `claude-code`, `agents` → `agents`) and prints a deprecation notice. Prefer
> `--harness`.
### Health check
`naba doctor` validates your environment and exits non-zero if any check fails:
```bash
naba doctor # checks skills install, API key, model, config
naba doctor --json # structured output
naba doctor --harness agents # check the agents-harness install instead
```
It reports: skills installed and matching this binary (integrity marker present,
up-to-date, complete, unmodified); the **effective provider's** API key present (it resolves the
effective provider — CLI `--provider`, else config `provider`, else env-key autodetect — then
checks that provider's key); the
key live-valid (a cheap `models.list` call, no image cost); the configured model reachable;
config parseable; and the binary version.
### Skill-gate preflight
`naba skills preflight --json` is a fast, **offline** gate the `/naba` skill runs at trigger
time (`naba doctor` is the full, network-touching sweep; preflight is the lightweight
per-invocation check):
```bash
naba skills preflight --json
```
It reports three axes: **auth** (the effective provider's key is present — no network call),
**skills** (the installed skill tree matches this binary), and **binary** — a tri-state
`up_to_date | update_available | unknown`. The binary axis reads the offline update-check
cache; an absent/stale cache is `unknown` and **non-blocking** (a fresh install always
passes). Overall `status` is `ok` unless auth or skills fails (`auth_missing` /
`skills_outdated`); the gate exits non-zero on a non-`ok` status.
### Implicit triggering
You rarely type `/naba` yourself. The skill's description tells the agent to **trigger it
automatically** whenever your request matches an image task — even in plain language. Any of
these fire the right subcommand with no slash command:
- "make me an image of a red apple on white" → `generate`
- "remove the background from logo.png" → `edit`
- "sharpen and denoise this old photo" → `restore`
- "an app icon for a rocket ship at 256 and 512" → `icon`
- "a seamless circuit-board texture" → `pattern`
- "draw a flowchart of the auth flow" → `diagram`
The skill **skips** requests for editable diagram *source* (d2/mermaid text) — `naba diagram`
produces a rendered image, not editable source. Explicit `/naba <subcommand>` invocation always
works too, and is the reliable trigger when you want a specific subcommand.
### Subcommands
Invoke as `/naba <subcommand> [args]`; run `/naba help` to print the dispatch table.
| Subcommand | Purpose |
|:-----------|:--------|
| `/naba generate` | Generate an image from a text prompt |
| `/naba edit` | Edit an existing image with text instructions |
| `/naba restore` | Restore or enhance an existing image |
| `/naba icon` | Generate app icons (optionally multi-size) |
| `/naba pattern` | Generate seamless patterns and textures |
| `/naba diagram` | Generate technical diagram images |
| `/naba story` | Generate a sequential image series |
| `/naba storyboard` | Composite: story sequence + per-frame edits |
| `/naba batch` | Composite: orchestrate multiple `naba` calls (icon suites, asset pipelines) |
| `/naba brand-kit` | Composite: icon + pattern + hero image set |
The seven inline subcommands run a single `naba` CLI call directly; the three composites
(`storyboard`, `batch`, `brand-kit`) dispatch a subagent that runs the multi-call loop and
returns a compact summary. Shared prompt guidance, anti-patterns, and the global-flags table
live once in `skills/naba/SKILL.md`.
## Global Flags
| Flag | Description |
|:-----|:------------|
| `--json` | Output structured JSON (auto-enabled when piped) |
| `-o, --output` | Output file path |
| `-q, --quiet` | Suppress progress output |
| `-m, --model` | Override the model (requires `--provider` on the CLI) |
| `--provider` | Provider: `gemini`, `openrouter`, or `bedrock` (see [Providers](#providers)) |
| `--no-input` | Disable interactive prompts |
The generative commands also accept `--aspect`, `--resolution` (imageConfig), and
`--quality` (per-provider — see [Models & pricing](#models--pricing)); see the
[Generate images](#generate-images) section.
## Output format
The provider returns the actual image format (Gemini returns **JPEG**; OpenRouter's
`/api/v1/images` returns **PNG**). `naba` writes the file with the matching extension: if your
`-o` path uses a different extension (e.g. `-o hero.png` against a JPEG response), `naba`
corrects it on disk (`hero.jpg`), warns on stderr, and reports both formats in JSON
(`requested_format` / `actual_format`) so you can decide whether a post-generation
conversion is needed.
## JSON Output
When `--json` is used (or stdout is piped), output includes:
```json
{
"path": "/absolute/path/to/image.jpg",
"command": "generate",
"prompt": "a red apple",
"elapsed_ms": 3200,
"params": {
"style": "watercolor",
"aspect": "16:9",
"resolution": "2K"
},
"requested_format": "png",
"actual_format": "jpeg"
}
```
`requested_format` appears only when `-o` implied a format; `actual_format` reflects the
response mimeType. They differ when the extension was corrected.
## Exit Codes
| Code | Meaning |
|:-----|:--------|
| 0 | Success |
| 1 | General error |
| 2 | Usage error |
| 3 | Authentication error |
| 4 | Rate limit exceeded |
| 5 | API error |
| 10 | File I/O error |
## Contributing
Contributions are welcome — including AI-assisted ones (`naba` is itself built with
AI agents). See [CONTRIBUTING.md](CONTRIBUTING.md) for how the project is
constructed, the local validation gate every change must pass, how to file issues,
and the AI-assisted contribution policy. Please also read the
[Code of Conduct](CODE_OF_CONDUCT.md); report security issues privately per the
[Security Policy](SECURITY.md).
## License
MIT - see [LICENSE](LICENSE)
MCP Config
Below is the configuration for this MCP Server. You can copy it directly to Cursor or other MCP clients.
mcp.json
Connection Info
You Might Also Like
No recommendations available