> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inheribase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Specification: Tool Definitions and Authentication

> Technical reference for the Inheribase MCP server v2.0 — tool schemas, authentication, JSON-RPC protocol, and security best practices.

This is the technical reference for the Inheribase MCP server v2.0. It covers the authentication protocol, full tool definitions with argument and return schemas, a JSON-RPC implementation example, and security best practices for integrators building on top of the Inheribase protocol.

## Protocol authentication

Agents connecting via MCP must provide a valid API key in the `INHERIBASE_API_KEY` environment variable. Inheribase supports two key classes with different permission scopes:

| Key type         | Prefix         | Access                                                         |
| ---------------- | -------------- | -------------------------------------------------------------- |
| Human-bound key  | `sk_human_...` | Unrestricted access to the user's vault                        |
| Scoped agent key | `sk_agent_...` | Restricted to specific tools like `check_in` and `store_asset` |

Set the key in your MCP server environment before starting the server:

```bash theme={null}
export INHERIBASE_API_KEY=sk_agent_your_key_here
```

## Tool definitions

### 1. store\_asset

Persists a file to the vault with client-side encryption. The file content is encrypted on the agent before it is transmitted to Inheribase.

**Arguments:**

| Name       | Type     |          | Description                        |
| ---------- | -------- | -------- | ---------------------------------- |
| `filename` | `string` | Required | The destination path in the vault  |
| `data`     | `string` | Required | Base64-encoded file content        |
| `metadata` | `object` | Optional | Tags or descriptions for the asset |

**Returns:**

| Name        | Type     | Description                                 |
| ----------- | -------- | ------------------------------------------- |
| `hash`      | `string` | The Arweave transaction ID                  |
| `timestamp` | `string` | The cryptographic anchoring time (ISO 8601) |

***

### 2. check\_status

Retrieves the current state of the vault and succession timeline.

**Arguments:**

| Name      | Type     |          | Description                         |
| --------- | -------- | -------- | ----------------------------------- |
| `vaultId` | `string` | Optional | Defaults to the key's primary vault |

**Returns:**

| Name            | Type     | Description                                 |
| --------------- | -------- | ------------------------------------------- |
| `state`         | `string` | One of `active`, `releasing`, or `released` |
| `daysRemaining` | `number` | Days until the current trigger executes     |

***

### 3. check\_in

Executes an Audit Pulse to reset the Dead Man's Switch timer. This confirms the user is active and restarts the check-in countdown.

**Arguments:**

| Name   | Type     |          | Description                           |
| ------ | -------- | -------- | ------------------------------------- |
| `note` | `string` | Optional | A brief log entry for the audit trail |

**Returns:**

| Name             | Type     | Description                                       |
| ---------------- | -------- | ------------------------------------------------- |
| `nextCheckInDue` | `string` | ISO timestamp of the next required Vitality Event |

## Implementation example

The following JSON-RPC payload demonstrates how to call the `check_in` tool from a compatible MCP client:

```json theme={null}
{
  "method": "tools/call",
  "params": {
    "name": "check_in",
    "arguments": {
      "note": "Daily automated status verification"
    }
  }
}
```

## Security best practices

1. **Never share `sk_human_...` keys.** Use scoped `sk_agent_...` keys for shared or automated integrations. Human-bound keys grant unrestricted vault access and should only be used in fully controlled personal environments.

2. **Handle 402 errors in `store_asset` calls.** The MCP server returns a `402` status when the Vault Credits balance is insufficient to store a file. Build retry logic that checks for credits before attempting large uploads.

3. **Review the audit trail regularly.** All MCP actions are logged in your vault's Activity Monitoring section. Review these logs periodically to verify that agent activity matches your expectations.