@toolrelay/cli 1.0.0 → 1.1.0

package/LICENSE

@@ -0,0 +1,6 @@
+Copyright (c) 2024-2026 ToolRelay, Inc. All rights reserved.
+
+This software is proprietary and confidential. Unauthorized copying, distribution,
+modification, or use of this software, via any medium, is strictly prohibited.
+
+Use of this software is governed by the terms of service at https://toolrelay.io/terms.

package/README.md

@@ -1,30 +1,60 @@
 # @toolrelay/cli
 
-CLI for [ToolRelay](https://toolrelay.io) — define your API tools in a `toolrelay.json` config file, validate it, serve a local MCP server, and deploy to the cloud. Every tool call produces a detailed audit trace.
+Turn any REST API into an MCP server that AI agents can use — in one command.
+
+Define your API endpoints in a JSON config, and the CLI gives you a local [Model Context Protocol](https://modelcontextprotocol.io) server that Claude, GPT, and other AI agents can connect to instantly. No SDK integration, no code changes, no infrastructure to manage.
+
+## Why
+
+AI agents need tools. Your API already exists. The gap between the two is boilerplate: building an MCP server, handling auth, mapping parameters, debugging what the agent actually sent. This CLI closes that gap.
+
+- **Zero code** — describe your API in JSON, get a working MCP server
+- **Works with any REST API** — GET, POST, PUT, DELETE with path, query, body, and header parameters
+- **Built-in auth** — static tokens, API keys, OAuth 2.0 (with PKCE), custom headers
+- **Audit traces** — every tool call logs the full request/response cycle so you can see exactly what happened
+- **Session viewer** — browse past sessions in a local web UI, like Playwright's HTML reporter for API calls
+- **Environment variable interpolation** — `${VAR}` syntax keeps secrets out of committed config files
+- **Deploy when ready** — one command to go from local testing to a hosted MCP endpoint at [toolrelay.io](https://toolrelay.io)
 
 ## Quick start
 
 ```bash
-# Interactive wizard — walks you through app and tools
 npx @toolrelay/cli init
+```
 
-# Or skip prompts with a starter template
-npx @toolrelay/cli init --yes
+The wizard walks you through your API — name, base URL, auth, and endpoints. It generates a `toolrelay.json` config file.
 
-# Validate config
-npx @toolrelay/cli validate toolrelay.json
+Then start the MCP server:
 
-# Start a local MCP server for Claude Desktop
+```bash
 npx @toolrelay/cli serve toolrelay.json
+```
+
+That's it. Add the printed URL to Claude Desktop's config and your API is available as tools.
+
+## How it works
 
-# Deploy to ToolRelay
-npx @toolrelay/cli login
-npx @toolrelay/cli publish toolrelay.json
 ```
+                  toolrelay.json
+                       |
+    npx @toolrelay/cli serve toolrelay.json
+                       |
+          Local MCP Server (localhost:8787)
+           /            |            \
+     tools/list    tools/call     health
+                       |
+              Your REST API backend
+```
+
+1. You describe your API in `toolrelay.json` — endpoints, parameters, auth
+2. `serve` starts a local MCP Streamable HTTP server
+3. AI agents connect and discover your tools via `tools/list`
+4. When an agent calls a tool, the CLI maps parameters, injects auth, and proxies the request to your backend
+5. Every call is logged with full audit traces — request, response, timing, errors
 
-## Config file format (`toolrelay.json`)
+## Config file
 
-The `init` wizard generates this file for you, or you can create it manually:
+The `init` wizard generates this, or create it by hand:
 
 ```json
 {
@@ -32,7 +62,7 @@ The `init` wizard generates this file for you, or you can create it manually:
     "name": "My API",
     "base_url": "http://localhost:3000",
     "auth_type": "static_token",
-    "auth_config": { "token": "my-dev-key" }
+    "auth_config": { "token": "${API_TOKEN}" }
   },
   "tools": [
     {
@@ -48,125 +78,46 @@ The `init` wizard generates this file for you, or you can create it manually:
 }
 ```
 
-> **Tip:** `description` on both tools and parameters is how AI agents understand what your API does. Always include clear descriptions — they directly affect how well agents use your tools.
-
-### Environment variable interpolation
+> **Tip:** `description` on both tools and parameters is how AI agents decide which tool to use. Clear descriptions directly improve how well agents interact with your API.
 
-Use `${VAR_NAME}` syntax to reference environment variables in any string field. This keeps secrets out of your config file:
+### Environment variables
 
-```json
-{
-  "app": {
-    "base_url": "${API_BASE_URL}",
-    "auth_type": "static_token",
-    "auth_config": { "token": "${API_TOKEN}" }
-  }
-}
-```
+Use `${VAR_NAME}` in any string field to reference environment variables. Secrets stay out of your config:
 
 ```bash
-export API_BASE_URL=http://localhost:3000
-export API_TOKEN=my-secret-key
+export API_TOKEN=sk-my-secret-key
 npx @toolrelay/cli serve toolrelay.json
 ```
 
-If a referenced variable is missing, the CLI fails with a clear error listing the missing variable names. This works for `base_url`, `auth_config` values, `headers_template`, and any other string field.
+If a referenced variable is missing, the CLI fails with a clear error listing the missing names.
 
 ### Auth types
 
-| `auth_type` | `auth_config` fields | Description |
+| `auth_type` | `auth_config` | Description |
 |---|---|---|
 | `none` | — | No authentication |
 | `static_token` | `{ "token": "..." }` | Bearer token in Authorization header |
 | `api_key_relay` | `{ "header_name": "X-API-Key" }` | Consumer API keys relayed to backend |
-| `custom_header` | `{ "headers": { "X-Custom": "value" } }` | Custom headers with static values |
-| `oauth2` | `{ "authorize_url", "token_url", "client_id"?, "client_secret"?, "scopes"?, "use_pkce"? }` | OAuth 2.0 authorization code flow (see [OAuth2 section](#oauth2-local-testing)) |
+| `custom_header` | `{ "headers": { "X-Custom": "value" } }` | Custom header name/value pairs |
+| `oauth2` | `{ "authorize_url", "token_url", ... }` | OAuth 2.0 with PKCE (see [OAuth2 section](#oauth2)) |
 
 ### Parameter mapping
 
-Each parameter in `parameter_mapping` specifies:
+Each parameter in `parameter_mapping` tells the CLI how to translate what the agent sends into what your API expects:
 
 | Field | Required | Description |
 |---|---|---|
 | `name` | yes | Parameter name (what the AI agent sends) |
 | `type` | yes | `string`, `number`, `boolean`, `object`, or `array` |
 | `required` | yes | Whether the parameter is required |
-| `target` | yes | Where the parameter goes: `path`, `query`, `body`, or `header` |
+| `target` | yes | Where it goes: `path`, `query`, `body`, or `header` |
 | `backend_key` | no | Backend field name if different from `name` |
-| `default` | no | Default value when not provided |
-| `description` | no | Human-readable description (shown to AI agents) |
-
-#### Path parameters
-
-Path parameters replace `{placeholder}` segments in the `endpoint_path`. The parameter `name` (or `backend_key` if set) must match the placeholder name.
-
-```json
-{
-  "name": "create-order",
-  "http_method": "POST",
-  "endpoint_path": "/api/customers/{customer_id}/orders",
-  "parameter_mapping": [
-    { "name": "customer_id", "type": "string", "required": true, "target": "path" }
-  ]
-}
-```
-
-Agent sends `{ "customer_id": "cust_42" }` → request goes to `/api/customers/cust_42/orders`.
-
-#### Query parameters
-
-Query parameters are appended as `?key=value` to the URL. Use `backend_key` when the backend expects a different name than what the agent sends, and `default` for optional filters.
+| `default_value` | no | Default when not provided |
+| `description` | no | Shown to AI agents — always include this |
 
-```json
-{
-  "name": "search_products",
-  "http_method": "GET",
-  "endpoint_path": "/api/products",
-  "parameter_mapping": [
-    { "name": "query", "type": "string", "required": true, "target": "query", "backend_key": "q" },
-    { "name": "category", "type": "string", "required": false, "target": "query" },
-    { "name": "page", "type": "number", "required": false, "target": "query", "default": 1 },
-    { "name": "limit", "type": "number", "required": false, "target": "query", "default": 20 }
-  ]
-}
-```
-
-Agent sends `{ "query": "bluetooth speaker", "category": "electronics" }` → request goes to `/api/products?q=bluetooth+speaker&category=electronics&page=1&limit=20`.
-
-#### Body parameters
-
-Body parameters are sent as JSON in the request body. Use dot-notation in `backend_key` to create nested objects (e.g., `address.city` becomes `{ "address": { "city": "..." } }`).
-
-```json
-{
-  "name": "create_contact",
-  "http_method": "POST",
-  "endpoint_path": "/api/contacts",
-  "parameter_mapping": [
-    { "name": "name", "type": "string", "required": true, "target": "body" },
-    { "name": "email", "type": "string", "required": true, "target": "body" },
-    { "name": "phone", "type": "string", "required": false, "target": "body" },
-    { "name": "city", "type": "string", "required": false, "target": "body", "backend_key": "address.city" },
-    { "name": "state", "type": "string", "required": false, "target": "body", "backend_key": "address.state" },
-    { "name": "tags", "type": "array", "required": false, "target": "body", "default": [] }
-  ]
-}
-```
-
-Agent sends `{ "name": "Alice", "email": "alice@example.com", "city": "Austin", "state": "TX" }` → request body becomes:
-
-```json
-{
-  "name": "Alice",
-  "email": "alice@example.com",
-  "address": { "city": "Austin", "state": "TX" },
-  "tags": []
-}
-```
-
-#### Mixing targets
+**Path** parameters replace `{placeholder}` in the URL. **Query** parameters are appended as `?key=value`. **Body** parameters are sent as JSON (use dot-notation in `backend_key` for nesting, e.g. `address.city`). **Header** parameters are injected as HTTP headers.
 
-A single tool can combine path, query, body, and header parameters:
+A single tool can mix all four targets:
 
 ```json
 {
@@ -175,286 +126,139 @@ A single tool can combine path, query, body, and header parameters:
   "endpoint_path": "/api/items/{item_id}",
   "parameter_mapping": [
     { "name": "item_id", "type": "string", "required": true, "target": "path" },
-    { "name": "dry_run", "type": "boolean", "required": false, "target": "query", "default": false },
+    { "name": "dry_run", "type": "boolean", "required": false, "target": "query", "default_value": false },
     { "name": "title", "type": "string", "required": true, "target": "body" },
-    { "name": "price", "type": "number", "required": true, "target": "body" },
     { "name": "idempotency_key", "type": "string", "required": false, "target": "header", "backend_key": "Idempotency-Key" }
   ]
 }
 ```
 
-Agent sends `{ "item_id": "abc", "title": "Widget", "price": 9.99, "idempotency_key": "req-1" }` → `PUT /api/items/abc?dry_run=false` with body `{ "title": "Widget", "price": 9.99 }` and header `Idempotency-Key: req-1`.
-
 ## Commands
 
-### `init` — Generate a config file
-
-```bash
-npx @toolrelay/cli init              # Interactive wizard
-npx @toolrelay/cli init --yes        # Starter template (no prompts)
-```
-
-Walks you through configuring your app (name, base URL, auth type) and defining tools (endpoints, parameters).
-
-### `validate` — Check config
-
-```bash
-npx @toolrelay/cli validate toolrelay.json
-```
-
-Validates the config without making any HTTP calls. Catches:
-
-- **Schema errors**: Missing required fields, invalid enum values, malformed URLs
-- **Path parameter mismatches**: `{placeholder}` in `endpoint_path` without a matching `target: "path"` parameter (and vice versa)
-- **Auth config**: Required fields per auth type (e.g., `token` for `static_token`, `authorize_url` for `oauth2`)
-
-Run this in CI to catch config issues before deploying.
-
 ### `serve` — Local MCP server
 
 ```bash
 npx @toolrelay/cli serve toolrelay.json
-npx @toolrelay/cli serve toolrelay.json --port 8787
+npx @toolrelay/cli serve toolrelay.json --port 9000 --verbose
 ```
 
-Starts a local MCP Streamable HTTP server that Claude Desktop (or any MCP client) can connect to. Every `tools/call` produces a full audit trace in your terminal.
+Starts a local MCP Streamable HTTP server. On startup it prints a Claude Desktop config snippet you can copy directly.
 
 | Option | Description |
 |---|---|
 | `--base-url <url>` | Override `base_url` from config |
-| `-p, --port <number>` | Port to listen on (default: 8787) |
+| `-p, --port <number>` | Port (default: 8787) |
 | `-v, --verbose` | Show response headers and extra detail |
 
-On startup it prints the Claude Desktop config snippet:
-
-```json
-{
-  "mcpServers": {
-    "my-api": {
-      "url": "http://localhost:8787/mcp"
-    }
-  }
-}
-```
-
-The server implements the full MCP Streamable HTTP protocol (`initialize`, `tools/list`, `tools/call`, `ping`, SSE, session management).
-
 **Endpoints:**
 
 | Endpoint | Description |
 |---|---|
-| `POST /mcp` | MCP JSON-RPC endpoint |
-| `GET /mcp` | SSE stream (with `Mcp-Session-Id` header) |
-| `GET /health` | Health check (tool count, call count, OAuth status) |
+| `POST /mcp` | MCP JSON-RPC (tools/list, tools/call, etc.) |
+| `GET /mcp` | SSE stream (with `Mcp-Session-Id`) |
+| `GET /health` | Health check + OAuth status |
 | `GET /timeline` | Call timeline as JSON |
-| `GET /oauth/start` | Trigger OAuth flow (OAuth2 apps only) |
-| `GET /oauth/status` | Check OAuth state (OAuth2 apps only) |
-
-**Call timeline:** Every tool invocation is tracked with sequence numbers, timestamps, arguments, status, latency, and the gap between calls (how long the AI spent "thinking"). On shutdown (Ctrl+C), a formatted timeline and audit summary are printed.
-
-**Session persistence:** Sessions are saved to `.toolrelay/sessions/` on shutdown. Browse them with `toolrelay ui`.
-
-### `ui` — Session viewer
-
-```bash
-npx @toolrelay/cli ui
-npx @toolrelay/cli ui --port 8788 --no-open
-```
-
-Opens a local web UI to browse past `serve` sessions. Inspect call timelines, drill into individual tool calls to see parameter resolution, request/response bodies, diagnostics, and errors.
+| `GET /oauth/start` | Trigger OAuth flow (OAuth2 apps) |
+| `GET /oauth/status` | Check OAuth state |
 
-| Option | Description |
-|---|---|
-| `-p, --port <number>` | Port to listen on (default: 8788) |
-| `--no-open` | Don't auto-open the browser |
+Every tool call is tracked with sequence number, timing, arguments, status, and the gap between calls. On Ctrl+C, a formatted timeline and summary are printed. Sessions are saved to `.toolrelay/sessions/` — browse them with `toolrelay ui`.
 
-### `login` — Authenticate with ToolRelay
+### `init` — Generate a config
 
 ```bash
-npx @toolrelay/cli login
+npx @toolrelay/cli init              # Interactive wizard
+npx @toolrelay/cli init --yes        # Starter template
 ```
 
-Opens your browser to sign in to [toolrelay.io](https://toolrelay.io). On success, your credentials are saved to `~/.toolrelay/credentials.json` (file mode `0600`).
-
-For CI/CD pipelines, set the `TOOLRELAY_DEPLOY_TOKEN` environment variable instead — it takes priority over the credentials file.
-
-### `logout` — Clear saved credentials
+### `validate` — Check config
 
 ```bash
-npx @toolrelay/cli logout
+npx @toolrelay/cli validate toolrelay.json
 ```
 
-Removes `~/.toolrelay/credentials.json`. Does not revoke the token server-side.
+Validates without making HTTP calls. Catches schema errors, path parameter mismatches, and missing auth fields. Run in CI to catch config issues before deploying.
 
-### `whoami` — Show current user
+### `ui` — Session viewer
 
 ```bash
-npx @toolrelay/cli whoami
+npx @toolrelay/cli ui
 ```
 
-Prints the authenticated user's email, name, and account tier. Useful for verifying which account the CLI is using.
+Opens a local web UI to browse past `serve` sessions. Drill into individual tool calls to see parameter resolution, request/response bodies, diagnostics, and errors.
 
-### `publish` — Deploy to ToolRelay
+### `publish` — Deploy to production
 
 ```bash
+npx @toolrelay/cli login
 npx @toolrelay/cli publish toolrelay.json
 npx @toolrelay/cli publish toolrelay.json --dry-run
-npx @toolrelay/cli publish toolrelay.json --prune
 ```
 
-Deploys your `toolrelay.json` config to the ToolRelay platform. The command is **idempotent** — it creates the app and tools on first run, then updates only what changed on subsequent runs.
-
-| Option | Description |
-|---|---|
-| `--dry-run` | Show what would change without making any API calls |
-| `--prune` | Delete remote tools that are no longer in the config file |
-
-**How it works:**
+Deploys your config to [ToolRelay](https://toolrelay.io). The command is idempotent — creates on first run, updates only what changed after that.
 
-1. Validates your config for production readiness (see [Pre-publish checks](#pre-publish-checks) below)
-2. Authenticates using `TOOLRELAY_DEPLOY_TOKEN` (env var) or `~/.toolrelay/credentials.json` (from `login`)
-3. Matches your local app to a remote app by slug (derived from `app.name`)
-4. Creates the app if it doesn't exist, or updates it if the config changed
-5. Syncs tools — creates new ones, updates changed ones, and optionally prunes removed ones
-6. Auto-publishes the app if it hasn't been published yet
+What you get after publishing:
 
-**What you get after publishing:**
-
-- A hosted MCP endpoint at `https://proxy.toolrelay.io/mcp/<your-slug>` — connect any AI agent
-- An API portal at `https://toolrelay.io/portal/<your-slug>` — consumers can request API keys
-- Auto-generated OpenAPI spec, SKILL.md, and landing page
-
-**Tier limits** are enforced by the API. If your plan doesn't support the number of apps or tools you're deploying, the command will fail with a clear error message.
-
-#### Pre-publish checks
-
-Before making any API calls, `publish` validates your config to catch common mistakes:
-
-| Check | Severity | Description |
-|---|---|---|
-| Localhost / private IP | Error | `base_url` cannot point to `localhost`, `127.0.0.1`, `192.168.*`, etc. |
-| HTTP base URL | Warning | Production APIs should use HTTPS |
-| Missing tool descriptions | Warning | AI agents rely on descriptions to pick the right tool |
-| OAuth2 required fields | Error | `authorize_url` and `token_url` must be set (`client_id`/`client_secret` are optional for public client PKCE) |
-| OAuth2 localhost URLs | Error | OAuth URLs must be publicly reachable |
-| Missing static token | Error | `static_token` auth requires a `token` in `auth_config` |
-| Duplicate tool names | Error | Each tool must have a unique name |
-
-Errors block the deploy. Warnings are printed but don't prevent publishing.
-
-**Authentication:**
+- **Hosted MCP endpoint** at `https://proxy.toolrelay.io/mcp/<your-slug>`
+- **Consumer portal** for API key self-service
+- **Auto-generated docs** — OpenAPI spec, SKILL.md, landing page
+- **Usage analytics** — call volume, latency, error rates per tool
+- **Rate limiting and caching** — per-consumer, per-tier controls
 
-| Method | Use case |
+| Option | Description |
 |---|---|
-| `toolrelay login` | Local development — opens browser, saves credentials to `~/.toolrelay/` |
-| `TOOLRELAY_DEPLOY_TOKEN` | CI/CD — set as environment variable, takes priority over credentials file |
+| `--dry-run` | Show what would change without making API calls |
+| `--prune` | Delete remote tools no longer in config |
 
-Generate a deploy token at **[toolrelay.io/dashboard/settings](https://toolrelay.io/dashboard/settings)** (Settings > Deploy Tokens). The token is shown once — copy it and store it as a CI secret.
+For CI/CD, use `TOOLRELAY_DEPLOY_TOKEN` instead of `toolrelay login`. Generate one at [toolrelay.io/dashboard/settings](https://toolrelay.io/dashboard/settings).
 
-**Environment variables:**
-
-| Variable | Description |
-|---|---|
-| `TOOLRELAY_DEPLOY_TOKEN` | Deploy token for authentication (takes priority over credentials file) |
-| `TOOLRELAY_API_URL` | Override the API endpoint (default: `https://api.toolrelay.io`) |
+## OAuth2
 
-## OAuth2 local testing
-
-When your app uses `auth_type: "oauth2"`, the `serve` command runs a full browser-based OAuth2 authorization code flow locally.
+When `auth_type` is `"oauth2"`, the `serve` command handles the full browser-based authorization code flow locally:
 
 ```json
 {
-  "app": {
-    "name": "My OAuth API",
-    "base_url": "http://localhost:3000",
-    "auth_type": "oauth2",
-    "auth_config": {
-      "authorize_url": "https://provider.com/oauth/authorize",
-      "token_url": "https://provider.com/oauth/token",
-      "client_id": "${OAUTH_CLIENT_ID}",
-      "client_secret": "${OAUTH_CLIENT_SECRET}",
-      "scopes": "read write"
-    }
-  },
-  "tools": [...]
+  "auth_config": {
+    "authorize_url": "https://provider.com/oauth/authorize",
+    "token_url": "https://provider.com/oauth/token",
+    "client_id": "${OAUTH_CLIENT_ID}",
+    "client_secret": "${OAUTH_CLIENT_SECRET}",
+    "scopes": "read write"
+  }
 }
 ```
 
-**How it works:**
-
-1. On startup, a temporary HTTP server starts on a random port for the OAuth callback
-2. Your browser opens to the upstream provider's authorize URL (with PKCE by default)
-3. After you authorize, the provider redirects to `http://localhost:<port>/callback`
-4. The CLI exchanges the authorization code for access/refresh tokens
-5. Tokens are stored in memory — every tool call gets `Authorization: Bearer <token>` injected automatically
-6. If the access token expires and a refresh token is available, it's refreshed automatically
+On startup, a browser window opens for authorization. After you approve, tokens are stored in memory and injected into every tool call automatically. Refresh is handled transparently.
 
-**Important:** Register `http://localhost` (any port) as an allowed redirect URI in your OAuth provider's settings.
+`client_id` and `client_secret` are optional — public client PKCE flows work without them.
 
-If the browser can't auto-open (headless environments, SSH), the authorize URL is printed to the terminal. You can also manually trigger the flow at any time via `GET /oauth/start`.
+Register `http://localhost` (any port) as a redirect URI in your OAuth provider.
 
-### Disabling PKCE
+### PKCE
 
-PKCE (Proof Key for Code Exchange) is enabled by default. Some providers — like AWS Cognito configured as a confidential client, or certain custom OAuth servers — may reject the extra `code_challenge` / `code_verifier` parameters. Set `"use_pkce": false` in `auth_config` to disable it:
-
-```json
-{
-  "app": {
-    "name": "Cognito API",
-    "base_url": "https://api.example.com",
-    "auth_type": "oauth2",
-    "auth_config": {
-      "authorize_url": "https://mypool.auth.us-east-1.amazoncognito.com/oauth2/authorize",
-      "token_url": "https://mypool.auth.us-east-1.amazoncognito.com/oauth2/token",
-      "client_id": "${COGNITO_CLIENT_ID}",
-      "client_secret": "${COGNITO_CLIENT_SECRET}",
-      "scopes": "openid profile",
-      "use_pkce": false
-    }
-  },
-  "tools": [...]
-}
-```
+PKCE is enabled by default. Set `"use_pkce": false` for providers that reject it (e.g., AWS Cognito confidential clients):
 
-| Provider | PKCE support | Recommendation |
+| Provider | PKCE | Recommendation |
 |---|---|---|
-| Auth0 | Yes | Leave default (`use_pkce: true`) |
-| Supabase | Yes (default since 2024) | Leave default |
-| Okta | Yes | Leave default |
-| Google | Yes | Leave default |
+| Auth0, Okta, Google, Supabase | Yes | Leave default |
 | AWS Cognito (public client) | Yes | Leave default |
-| AWS Cognito (confidential client) | May reject PKCE | Set `"use_pkce": false` |
-| Custom OAuth servers | Varies | Try default first; set `false` if you get errors about unknown parameters |
-
-## Local to production
+| AWS Cognito (confidential client) | May reject | Set `"use_pkce": false` |
 
-The typical workflow:
+## Workflow
 
 ```
-1. toolrelay init          → Generate toolrelay.json
-2. toolrelay serve         → Test locally with Claude Desktop
+1. npx @toolrelay/cli init          → Generate toolrelay.json
+2. npx @toolrelay/cli serve         → Test locally with Claude Desktop
 3. (iterate on config)
-4. toolrelay login          → Authenticate with toolrelay.io
-5. toolrelay publish        → Deploy to production
+4. npx @toolrelay/cli publish       → Deploy to production
 ```
 
-Once published, your app gets:
-
-- **Hosted MCP endpoint** (`/mcp/<slug>`) — any AI agent can connect
-- **Consumer portal** (`/portal/<slug>`) — API key self-service for developers
-- **Auto-generated docs** — OpenAPI spec, SKILL.md, landing page
-- **Usage analytics** — call volume, latency, error rates per tool
-- **Rate limiting and caching** — per-consumer, per-tier controls
-
-Sign up at [toolrelay.io](https://toolrelay.io) to get started.
-
 ### File locations
 
 | Path | Purpose |
 |---|---|
-| `toolrelay.json` | Your app + tool config (project root, committed to git) |
-| `.toolrelay/sessions/` | Local MCP session logs (project-local, auto-gitignored) |
-| `~/.toolrelay/credentials.json` | Login credentials (home directory, mode `0600`) |
+| `toolrelay.json` | App + tool config (committed to git) |
+| `.toolrelay/sessions/` | Local session logs (auto-gitignored) |
+| `~/.toolrelay/credentials.json` | Login credentials (mode `0600`) |
 
 ## License
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@toolrelay/cli",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "type": "module",
   "description": "CLI for ToolRelay — validate configs, serve local MCP servers, and deploy to production with audit traces",
   "bin": {
@@ -9,7 +9,8 @@
   "main": "./dist/index.js",
   "files": [
     "dist",
-    "README.md"
+    "README.md",
+    "LICENSE"
   ],
   "keywords": [
     "toolrelay",