# apexe Quick Start
> Turn any CLI tool into an AI-callable MCP service in 30 seconds.
## Install
```bash
git clone https://github.com/aiperceivable/apexe.git
cd apexe
cargo install --path .
apexe --version
```
## 30 seconds: Scan, Serve
```bash
apexe scan git
apexe serve --acl ~/.apexe/acl.yaml
```
`apexe scan` writes a deny-by-default ACL, but **it is not applied for you** —
`apexe serve` with no `--acl` enforces no access control at all, and every
scanned module is callable by every caller. Pass the flag, and read the policy
before you trust it: it is generated by a name-based heuristic, not approved by
you. See [Threat model §5.2 and §5.3](threat-model.md).
## Claude Desktop Integration
```bash
apexe serve --show-config claude-desktop
```
Copy the output into `~/Library/Application Support/Claude/claude_desktop_config.json`, then restart Claude Desktop.
The snippet reproduces whatever else you put on that command line, so pass the
flags you intend to serve with — above all `--bindings-dir` if you scanned
somewhere other than `~/.apexe/bindings`, since a client that launches `apexe
serve` without it finds no tools:
```bash
apexe serve --show-config claude-desktop --bindings-dir /srv/apexe/modules --acl ~/.apexe/acl.yaml
```
Credentials (`--auth-token`, `--jwt-secret`) are never written into the
snippet — set those on the client side.
## Cursor Integration
```bash
apexe serve --show-config cursor
```
Add the output to Cursor's MCP settings.
## HTTP Mode with Explorer UI
```bash
apexe serve --transport http --port 8000 --explorer
```
Open `http://127.0.0.1:8000` in a browser to explore available tools.
## A2A Agent Server
Serve the same scanned tools as an A2A agent instead of (or alongside) MCP:
```bash
apexe a2a
```
`apexe a2a` shares governance (ACL, logging, approval) with `apexe serve` — see [User Manual §10](user-manual.md#10-mcp-server) and §11 for details.
## What happened?
1. `apexe scan git` ran git's `--help`, parsed man pages, and checked shell completions.
2. Wrote one binding file per command into `~/.apexe/bindings/` — `cli.git.commit.binding.yaml`, `cli.git.log.binding.yaml`, and so on, each carrying a JSON Schema for that command. There is no single `git.binding.yaml`; the file name is the module id.
3. Wrote `~/.apexe/acl.yaml` with `default_effect: deny` — readonly commands get an explicit allow rule, destructive ones an explicit deny, and anything the scan could not classify falls through to deny.
4. `apexe serve --acl …` started an MCP server on stdio, exposing the scanned tools **under that policy**. Without `--acl` the same command serves the same tools with no access control.
Two things always apply, with or without a policy: every argument the schema
types as a path is checked against the [path guard](user-manual.md#97-path-guard-always-on),
and every subprocess runs environment-scrubbed, shell-free, output-capped and
under a timeout.
## Scan more tools
```bash
apexe scan ls curl jq
```
## See what you have
```bash
apexe list
apexe list --format json
```
## Next steps
```bash
# Deep scan with 3 levels of subcommands
apexe scan git --depth 3
# HTTP server for remote agents
apexe serve --transport http --port 8000
# SSE transport (deprecated upstream -- prefer --transport http)
apexe serve --transport sse --port 8000
# Also generate Claude Skills (.claude/skills/<id>/SKILL.md) per module
apexe scan git --skills-dir ./out
# Observability: /metrics (Prometheus) + /usage (HTTP/SSE only)
apexe serve --transport http --metrics
# Initialize a config file for customization
apexe config --init
# View resolved configuration
apexe config --show
```
See [User Manual](user-manual.md) for full documentation.