MCP Server

Keys and access

Harny's MCP server uses two kinds of bearer key, and each one reaches a different set of tools.

Copy page
View as Markdown

Two kinds of key

KeyStarts withReaches
App keyfsa_describe, get_snippet, diagnose (any key), plus the app tools provision_user, get_claim_link, get_setup_bundle.
Person's keyfsk_describe, get_snippet, diagnose (any key), plus the person tools list_tools, ingest_text, assemble_context, action_history, configure_oauth.

Calls are scoped to the key's user. A person's key works only with that person's memory and actions.

The keyless door

Without an Authorization header, the MCP server offers one tool: provision_app. It makes a new app and returns its app key once. Put that key in your secret store and nowhere else.

A coding agent that can run commands should follow https://harny.ai/auth.md instead. Its command never shows the key.

get_claim_link needs the app key. It returns a fresh one-time link for the app owner. It is not an API key. Open it to take ownership of the app.

Get a person's key

provision_user needs the app key. It adds a person, an end user of your app, or returns the one that exists. The answer carries the person's key once. Store it the same way you store the app key.

Create app keys

The console creates app keys.

Connect a client

Claude Code:

claude mcp add --transport http harny https://api.harny.ai/v1/mcp/mcp --header "Authorization: Bearer $HARNY_USER_KEY"

Cursor, in mcp.json:

{"mcpServers": {"harny": {"url": "https://api.harny.ai/v1/mcp/mcp", "headers": {"Authorization": "Bearer ${env:HARNY_USER_KEY}"}}}}

The MCP server accepts bearer keys and sign-in tokens. A sign-in token reaches what the app key reaches for one app, except provision_app, and never an owner-only change. How it works has the detail.

Limits

Calls follow the same limits and refusals as the REST routes they wrap. A call over the per-minute limit answers 429 with Retry-After.

Next