# Knotbind agent quickstart

Knotbind keeps customer-facing APIs and MCP integrations working as their contracts change. You can onboard without a browser.
The commands use this instance's public URL. For a self-hosted deployment, use its public HTTPS URL instead.

## 1. Create a workspace

```sh
curl -sS -X POST https://www.knotbind.com/api/v1/signup \
  -H 'content-type: application/json' \
  -d '{"company":"Your company","name":"Integration Agent","email":"you@example.com"}'
```

The response returns a one-time `kbk_` API key. Treat it as a secret and set it as `KNOTBIND_API_KEY`.

## 2. Connect a customer MCP server

```sh
curl -sS -X POST https://www.knotbind.com/api/v1/integration \
  -H "authorization: Bearer $KNOTBIND_API_KEY" \
  -H 'content-type: application/json' \
  -d '{"mcp_url":"https://api.example.com/mcp"}'
```

Knotbind initializes the server and discovers its tools. It then suggests a contract Check for each tool, built from the tool's own declared input and output schemas. A suggestion is not a Check: the Owner reviews each one in the dashboard and approves it before it runs on a schedule. Write-capable tools are never scheduled without that approval.

The first time an approved Check passes, Knotbind records the shape of the answer as its Baseline. A later answer with a different shape fails the Check, so a change nobody announced still opens a Finding. The Owner can accept the new shape as the new Baseline, and that decision is written to the Audit Record.

An Account can hold several MCP servers, each with its own tools, schema history, health and Findings. Every server is polled on its own schedule, and a tool schema that changes in a breaking way opens a Finding naming the tool and what changed. Credentials for a server are encrypted before they are stored and never appear in a Run, a Finding, an Audit Record or a page. A server that needs OAuth is connected through the owner's own authorization, with PKCE and a refresh token. See https://docs.knotbind.com/docs/mcp-servers for the full model.

## 3. Read the result

```sh
curl -sS https://www.knotbind.com/api/v1/status -H "authorization: Bearer $KNOTBIND_API_KEY"
```

Use https://www.knotbind.com/api/v1/runs for Run evidence and https://www.knotbind.com/api/v1/finding for the current Finding. MCP clients can use https://www.knotbind.com/mcp with OAuth 2.1/PKCE or a Bearer key.

## 4. One-time tool calls

Use `POST https://www.knotbind.com/api/v1/tools/call` for one deliberate MCP tool call. It does not create a recurring Check. Write-capable tools require explicit `allow_write: true`, appropriate scope and Owner authorization. Never retry an uncertain write until checking the upstream system.

## Boundaries

Knotbind can connect, check, diagnose and propose. Only the Owner can approve, reject or deploy production changes. Knotbind's Stripe Checkout is for a Knotbind subscription; customer orders and payments must use the customer's own tool.

## More documentation

- https://docs.knotbind.com/docs/agent-api — REST, MCP and CLI
- https://docs.knotbind.com/docs/mcp — OAuth and assistant connection
- https://docs.knotbind.com/docs/mcp-servers — MCP registry, contract Checks, Baselines and workflows
- https://docs.knotbind.com/docs/plugins — Gateway modules (Semantic Cache, Guardrails, Failover, Rate Limits, Analytics)
- https://docs.knotbind.com/docs/quickstart — guided walkthrough
- https://www.knotbind.com/openapi.json — OpenAPI schema