harnyMCP Server
MCP tools
The Harny MCP server gives your coding assistant 12 tools, grouped by what they do and which key they need.
Copy page
To store a memory, call ingest_text. To recall what is known about a person, call assemble_context.
The tools
| Tool | Group | Reads or writes | Needs | What it does |
|---|---|---|---|---|
| provision_app | Apps and keys | writes | no key | Set up long-term memory for an app with no account: makes a new app and its key, as POST /v1/auth/provision does. The answer carries the app key once; the assistant is told to put it in the owner's secret store and nowhere else. |
| describe | Organization | reads | a key | What Harny is and what this key reaches. Harny is a private long-term memory for each person who uses an app: remember what a user tells you, recall it later, store user preferences. Returns the tools this key may call with their schemas. The first call an assistant should make. |
| get_snippet | Organization | reads | a key | A ready-to-use code snippet for one Harny capability. |
| list_tools | Organization | reads | a person's key | The tools available to the person whose key you hold, with whether each source is connected. |
| get_claim_link | Apps and keys | writes | the app key | A fresh one-time link the owner opens to take ownership of the app. It is not an API key. |
| get_setup_bundle | Apps and keys | reads | the app key | The setup bundle a coding assistant uses to stand up the app's agent: app facts, key variable names (never key values), sources to connect, the acting policy as the business set it, the model preset, deploy recipes. |
| ingest_text | Memory | writes | a person's key | Remember this: stores a text note, a user preference or a durable fact in that person's long-term memory, as POST /v1/vault/ingest/text does. Use it for what a user told you that should outlast the session. Subject to the app's ingest quotas. Not for streaming conversation transcripts. |
| assemble_context | Memory | reads | a person's key | Recall what is known about one person: searches their long-term memory and connected sources and returns ranked context, such as the preferences and facts stored for them. Use it before you answer, to remember who the user is and what they said earlier. Works as POST /v1/context/assemble does. Read-only. |
| action_history | Memory | reads | a person's key | The app's recorded actions for that person, newest first, each with a one-line summary. Query is a substring of the action's target name. |
| provision_user | Members and access | writes | the app key | Adds a person (an end user of the app) or returns the one that exists, as POST /v1/users does. The answer carries the person's key once. |
| configure_oauth | Members and access | writes | a person's key | Starts connecting one source (gmail, calendar, drive, notion, slack, email_bridge) for one person and returns the link they open to approve it. |
| diagnose | Debugging | reads | a key | Where the app's Harny connection stands and what to do about it: the state of each part, and how fresh each connected source is. |
Connect the server
The server address is https://api.harny.ai/v1/mcp/mcp over Streamable HTTP. With no Authorization header, only provision_app is listed. With Authorization: Bearer <key>, the tools for that key are listed. A person's key starts fsk_; the app key starts fsa_. The server accepts bearer keys and sign-in tokens; how it works explains sign-in.
claude mcp add --transport http harny https://api.harny.ai/v1/mcp/mcp --header "Authorization: Bearer $HARNY_USER_KEY"{"mcpServers": {"harny": {"url": "https://api.harny.ai/v1/mcp/mcp", "headers": {"Authorization": "Bearer ${env:HARNY_USER_KEY}"}}}}A coding agent that can run commands should follow https://harny.ai/auth.md instead of provision_app. Its command never shows the key.
Apps and keys
provision_app needs no key. provision_user, get_setup_bundle and get_claim_link need the app key, fsa_. get_claim_link returns a one-time link for the owner, not an API key. Keep the app key in your secret store. The console creates app keys.
Organization
describe, get_snippet and list_tools are read-only. Call describe first. describe and get_snippet take any key. list_tools needs a person's key and shows which sources that person has connected.
Memory
ingest_text, assemble_context and action_history need a person's key, fsk_. Calls are scoped to the key's user. ingest_text is subject to the app's ingest quotas and is not for streaming conversation transcripts. assemble_context is read-only. action_history lists the app's recorded actions for that person, newest first. Calls follow the same limits and refusals as the REST routes they wrap. A call over the per-minute limit returns 429 with Retry-After.
Members and access
provision_user adds a person or returns the one that exists, and returns their key once. configure_oauth starts a source connection for one person and returns a link. That person opens the link to approve it. Harny reads only that person's connected account.
Debugging
diagnose needs any key. It shows the state of each part of the app's Harny connection and how fresh each connected source is.