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
Two kinds of key
| Key | Starts with | Reaches |
|---|---|---|
| App key | fsa_ | describe, get_snippet, diagnose (any key), plus the app tools provision_user, get_claim_link, get_setup_bundle. |
| Person's key | fsk_ | 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.
Claim link
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.