deeptap-mcp
# deeptap-mcp
MCP server for [DeepTap](https://deeptap.io) — configure iOS Universal Links and Android App Links, and verify them, directly from your coding agent (Claude Code, etc.).
It's a thin wrapper over the DeepTap public REST API: each tool is one API call. Point your agent at it, and it can create a deep-link domain, wire up the iOS/Android config, and run a pre-flight check on the generated `apple-app-site-association` and `assetlinks.json` files.
## Install
Get an API key from **Dashboard → Settings → API Keys** at <https://deeptap.io/dashboard/settings>, then add the server:
```bash
claude mcp add --scope user --transport stdio deeptap \
--env DEEPTAP_API_KEY=dt_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
-- npx -y deeptap-mcp
```
Or run it directly: `DEEPTAP_API_KEY=dt_live_… npx -y deeptap-mcp`.
## Configuration
| Env var | Required | Default | Description |
|---|---|---|---|
| `DEEPTAP_API_KEY` | yes | — | API key (`dt_live_…`), sent as `Authorization: Bearer`. |
| `DEEPTAP_API_URL` | no | `https://deeptap.io` | Base URL of the DeepTap API (override for self-hosting/staging). |
## Tools
| Tool | API call | Purpose |
|---|---|---|
| `get_account` | `GET /me` | Account, plan, and live limits. Call first to check capacity. |
| `list_domains` | `GET /domains` | All domains with their iOS/Android config and file URLs. |
| `get_domain` | `GET /domains/:id` | One domain by id (e.g. `dom_42`). |
| `create_domain` | `POST /domains` | Create a subdomain and configure iOS/Android. |
| `update_domain` | `PUT /domains/:id` | Partial update of iOS/Android config. |
| `verify_domain` | `GET /domains/:id/verify` | Pre-flight: fetch and validate AASA + assetlinks. |
Every response includes a `meta` block with the plan, domain/link usage, and rate-limit state — the agent reads it to report limits.
### Typical flow
1. `get_account` — check the plan and how many domains are available.
2. `create_domain` — `{ "name": "myapp", "ios": { "team_id": "ABCDE12345", "bundle_id": "com.example.myapp", "paths": ["*"], "fallback_url": "https://example.com" }, "android": { "package_name": "com.example.myapp", "sha256_fingerprints": ["AA:BB:…"] } }`
3. `verify_domain` — confirm the generated files are reachable and match the app identifiers.
`verify_domain` checks everything verifiable server-side (file reachability, JSON validity, `appID`/package match, fingerprints, paths). Rebuilding the app and on-device checks are still required — the agent should also confirm `associatedDomains` / package config in your project (`app.json`, Xcode).
## Development
```bash
npm install
npm run build # tsc -> dist/
npm start # run the built server on stdio
```
## License
MIT
TDQS
Scored across 6 tools
Each tool has a unique purpose: account info, domain verification, listing, retrieval, creation, and updating. No two tools overlap, and the distinction between list/get and create/update is clear.
All tools follow a consistent verb_noun pattern in snake_case (get_account, verify_domain, list_domains, get_domain, create_domain, update_domain). This makes the API predictable and easy to navigate.
With 6 tools, the server covers its domain management purpose without excess. Each tool is necessary and the count is typical for a focused CRUD-style API.
The domain lifecycle is mostly complete with list, get, create, and update, but a delete_domain operation is missing. The verify_domain tool adds value, yet the absence of delete is a minor gap for full resource management.