Watch every MCP server you run.

Knotbind keeps a registry of your MCP servers. Each one is polled on its own schedule, its tools are fingerprinted, and a change nobody announced opens a Finding instead of breaking your assistants quietly.

Add a server

Open MCP tools in the dashboard and add a server by name and URL, or use the API. The first poll discovers the server's tools and stores their schemas.

POST /api/v1/integration
{"mcp_url": "https://api.example.com/mcp"}

Credentials

A server can be open, use a bearer token, send an API key in a header you name, or require OAuth. A token you paste is encrypted with the application secret and never shown again — not on the page, not in a log, not in the Audit Record. If a deployment prefers to manage its own secrets, give the name of an environment variable instead and Knotbind reads the value from the process.

Knotbind as an OAuth client

Some MCP servers delegate to a user's own account and need OAuth rather than a pasted token. Knotbind speaks that role too, in the opposite direction from the one on the MCP and OAuth page: there, an assistant signs in to Knotbind; here, the Owner signs their server in to Knotbind.

1. Discover

   Knotbind reads the server's protected-resource metadata, then the authorization server's metadata, falling back from RFC 8414 to OpenID Connect discovery.

2. Authorize

   The Owner is sent to the authorization server. The request carries PKCE and the RFC 8707 resource parameter, so the token is issued for this server and no other.

3. Exchange

   The one-time code is exchanged for an access token and a refresh token. The access token is sealed with the application secret; the refresh token is stored beside it and renews the access token when it expires.

Contract Checks

For every tool Knotbind discovers, it suggests a Check built from that tool's own declared schemas: the arguments it takes, and the shape it promises to return. A suggestion is not a Check. The Owner reviews each one and approves it before it runs on a schedule, and a tool that can change data is never scheduled without that approval.

Baselines

The first time an approved Check passes, Knotbind records the shape of the answer. A later answer with a different shape fails the Check: a field that appeared, or disappeared, is a change that somebody should look at. When the change was intended, the Owner accepts the new shape as the new Baseline, and that decision is written to the Audit Record under their name.

Workflow Checks

A single tool call is often only half the story. A Workflow Check calls one tool after another, so a later step can use what an earlier step returned — the customer id from a search, the order from a lookup.

[{"serverId":"mcp_1","toolName":"search_customers","parameters":{"email":"test@example.com"},"extractOutputAs":"customer"},
 {"serverId":"mcp_1","toolName":"get_orders","parameters":{"customerId":"{{customer.id}}"}}]

Each step can assert the shape it expects, and every step records its own duration and evidence. A failed step stops the workflow unless it says otherwise.

Drift, Findings and health

Every tool schema is fingerprinted. When a schema changes, Knotbind compares it against the fingerprint it recorded last time and decides whether the change breaks anyone: a new required parameter, a changed type, or a removed tool breaks callers; an added optional parameter does not.

A breaking change opens a Finding in the Reliability Loop and notifies the Owner by email, Slack or webhook — once per change, not once per poll. Each server also carries its own status: healthy, degraded while it is failing, or offline once it has failed three polls in a row. The Owner hears about an outage once, and hears about it again if the server comes back and later fails again.

OpenAPI from your tools

Knotbind can describe a registered server's tools as an OpenAPI 3.1 document, so tools that are meant for agents can also be read by OpenAPI tooling, code generators and linters. Each tool becomes one operation. A tool that can write is marked as needing approval. That mark is not the hosted pause. A hosted OpenAPI write waits for the one-time Owner approval described on OpenAPI to MCP.

GET /dashboard/mcp-servers/{id}/openapi.json