# Hjarni — Full LLM Context

> Everything an AI assistant needs to use a Hjarni knowledge base via the MCP server or REST API. This file is auto-generated from the live tool definitions, so it stays in sync with what the server actually exposes.

If you are an AI assistant a user pasted this URL to, follow the "Onboarding script" section below.

## How to connect

Hjarni speaks MCP (Model Context Protocol) over Streamable HTTP and supports OAuth 2.0 with PKCE for browser-capable clients.

- MCP endpoint: `https://hjarni.com/mcp`
- OAuth discovery: `https://hjarni.com/.well-known/oauth-authorization-server`
- Protected resource metadata: `https://hjarni.com/.well-known/oauth-protected-resource`
- Authorization endpoint: `https://hjarni.com/authorize`
- Token endpoint: `https://hjarni.com/token`
- Dynamic client registration: `https://hjarni.com/register`

For clients that do not support OAuth (older MCP clients, scripts, automations), use a personal API token as a Bearer token against the same `/mcp` endpoint, or use the [REST API](https://hjarni.com/docs/api) directly.

Client-specific setup guides:

- ChatGPT: https://hjarni.com/docs/connect-chatgpt-mcp
- Claude (Claude.ai, Claude Desktop, Claude iOS, Claude Code): https://hjarni.com/docs/connect-claude-mcp
- MCP server reference (transports, troubleshooting): https://hjarni.com/docs/mcp

## Onboarding script

After the user has connected the MCP server, walk them through this in order:

1. Call `instructions-get` with `level: "brain"` to read any account-wide preferences. If the response is empty, the user is new.
2. Call `dashboard-get` to see counts of notes, containers, and tags. A near-empty dashboard means this is a fresh account.
3. Call `containers-list` with `scope: "all"` to see the existing folder structure. Reuse what's there before creating anything new.
4. If the account is fresh, ask the user which persona best fits them (developer, founder, researcher, writer, or traveler) and what they want to capture. Then propose a starter container hierarchy. Wait for confirmation before creating anything.
5. Early on, ask the user a few questions about how they work. Naming conventions, tone, when to ask versus guess, things they never want to repeat in every chat. Save the answers with `instructions-update level: "brain"`. This is the account-wide preference block that rides along with every future conversation, and it is one of the signals Hjarni uses to mark onboarding complete.
6. After creating containers, proactively offer to set `instructions-update level: "container"` so future LLM sessions follow the same conventions in that folder. Container instructions layer on top of brain-level. Set them for things that only apply inside one folder.
7. When the user provides their first piece of real content, create the note with `notes-create`, include a 2-3 sentence `summary`, and place it in the most specific relevant container.

Always prefer asking the user before mutating their knowledge base. Show your plan, then act.

## Core concepts

- **Note**: a Markdown document with title, body, optional summary, tags, file attachments. Every edit is versioned. Notes can live in the personal space or inside a team.
- **Container**: a folder. Containers nest. Each can have its own LLM instructions that cascade to descendants.
- **Tag**: a cross-cutting label. Notes can have multiple tags. Tag names are lowercased.
- **Wiki-link**: `[[id:Title]]` inside a note body. The numeric ID is the source of truth; the title is cosmetic and stays in sync. Creates a bidirectional NoteLink automatically on save.
- **Summary**: a 2-3 sentence field on every note. Has a `summary_stale` flag set when the user edits the body directly — regenerate the summary when you encounter a stale one.
- **LLM instructions**: plain-language rules attached to the brain (account), the personal root, a container, or a team. Read with `instructions-get`, modify with `instructions-update`. Container instructions inherit from ancestors and from the personal root — follow all levels, they stack.
- **Team**: a shared space with its own notes, containers, and members. Caller must be a member to read or write.
- **Inbox**: unorganized personal notes (no container assigned). Surface them during a weekly review and offer to file them.

## Conventions an AI assistant should follow

- Search before creating. The note may already exist.
- Keep notes short and focused — one idea per note. When a topic is complex, create multiple short notes in a container and link them with `[[id:Title]]` rather than writing one long note.
- Always write a `summary` when creating a note. Always update the summary in the same call when you modify the body. Keep summaries to 2-3 sentences capturing the key takeaway.
- When you encounter a note with `summary_stale: true`, regenerate the summary using `notes-update`.
- Reuse existing tags. Call `tags-list` first; only create new tags when none of the existing ones fit.
- Before working in a container, check `has_llm_instructions` (returned on every container in list/search results). If true, call `instructions-get level: "container"` and follow every level of the inheritance chain.
- When the user expresses a durable preference ("always tag meeting notes", "use lowercase titles"), proactively offer to save it at the appropriate level. Read current instructions first, then merge — do not overwrite.
- For large file attachments, prefer `files-create_upload_url` (the user uploads directly via their browser) over `files-attach` (base64 through the conversation, wastes tokens). Use `files-attach_from_url` when the file is already at a public URL.

## Account-level instructions to LLM clients

The following text is also served as the MCP server's `instructions` capability. It is the source of truth for in-session conventions:

```
Second Brain is a personal knowledge management system with notes organized in a
hierarchy of containers (folders) and tagged for cross-cutting categorization.

IDENTITY & ONBOARDING:
- Call `me` once at the start of a conversation. It returns the user's first name,
  plan, team memberships, note quota, and onboarding state in a single call.
- Use first_name to greet the user (when present) and to personalize replies.
- If onboarding.completed is true, skip the onboarding script — the user is already
  set up. Otherwise walk through onboarding.missing_steps in order:
    * "connect_mcp"   — the user hasn't connected an MCP client yet.
    * "first_note"    — offer to create their first real note (notes-create).
    * "instructions"  — offer to capture their working preferences as brain
                        instructions (instructions-update with level: "brain").
- Use plan to avoid suggesting Pro features (file attachments, public sharing) to
  free users, and limits.notes_used / limits.notes_limit to warn before hitting
  the quota.
- Use the teams array to know which spaces are available before routing a note —
  e.g. ask "save this to <team name> or your personal brain?" when both apply.

SEARCHING:
- Use the search tool to search across notes, containers, and tags in one call.
  This is the fastest way to find anything.
- Use the types parameter to narrow results to specific types: ["notes"], ["containers"],
  ["tags"], or any combination. Defaults to all three.
- By default, search searches across personal notes AND all teams the user belongs to.
  Use the search_scope parameter to narrow results: "personal" for personal notes only,
  "team:<id>" for a specific team, or "all" (default) for everything.
- Team notes in search results include team_id and team_name fields so you can identify
  which team they belong to.
- Search results for notes include a snippet showing the matching portion of the note body.
- search and notes-list support multiple tags (AND logic) via the tags array,
  and include_nested to search within a container and all its sub-containers.
- Use search with types: ["containers"] to find a container by name or description
  instead of paginating through containers-list.

NOTE LINKING:
- Notes support wiki-link syntax: [[id:Note Title]] where id is the note's numeric ID
  and Note Title is the display text. The ID is the source of truth for resolution;
  the title is cosmetic and kept in sync automatically when a note is renamed.
- Wiki-links are the primary way to link notes. When a note is saved, [[id:Note Title]]
  references automatically create NoteLink records in the database. Removing a reference
  from the body automatically removes the link.
- Use this to cross-reference related notes inline. For example: "See [[42:Meeting Notes 2024]]
  for context." If the referenced note exists, it becomes a clickable link and appears in
  the "Linked Notes" section of the note page.
- The old [[Note Title]] format (without ID) is still supported as a fallback for
  existing notes that haven't been re-linked yet.
- The links-manage tool is available for programmatic linking without modifying
  note body text. These create persistent links that are not affected by body edits.

FILE ATTACHMENTS:
- When a user wants to attach a file (photo, PDF, document, etc.) to a note, prefer
  files-create_upload_url over files-attach. This generates a one-time upload link that
  you share with the user. They upload the file directly via their browser, which avoids
  sending large file data through the conversation and saves tokens.
- Flow: 1) Call files-create_upload_url with the note ID, 2) Share the returned upload_url
  with the user, 3) After the user uploads, call files-check_upload with the token to confirm.
- Use files-attach_from_url when the file is already at a public URL.
- Only use files-attach (base64) as a last resort for very small files.
- To retrieve/download a file, use files-get_download_url with the note_id and file_id
  (from notes-get response). This returns a temporary signed URL the user can open in their
  browser. The download_url is also included in file metadata whenever files appear in
  responses (e.g., notes-get, files-check_upload).

NOTE SIZE:
- Keep notes short and focused — each note should cover one idea, topic, or reference.
- When a topic is complex, create multiple short notes in a container and link them
  with wiki-links ([[id:Title]]) rather than writing one long note.
- Short notes are easier to search, link, reuse, and update independently.
SUMMARIES:
- Every note has a summary field and a summary_stale flag.
- When you create a note, always write a summary.
- When you update a note's body, always update the summary too in the same call.
- When you encounter a note with summary_stale: true, regenerate its summary
  using notes-update with the summary parameter. This flag means the user edited
  the note body directly and the summary is now outdated.
- Use notes-list with summary_stale: true to find all notes needing summary updates.
- Keep summaries to 2-3 sentences that capture the key takeaway.
- If the note's container has LLM instructions, follow those conventions
  for the summary style.

ORGANIZING:
- Always check the container hierarchy first using containers-list with scope "all" or
  search with types: ["containers"] to find the right container.
- Use containers-get with include_tree: true to see a container's ancestors and children.
- Check existing tags with tags-list and reuse them before creating new tags.
- Always ask the user to confirm where a note or container should be placed before
  creating or moving it.
- After creating a new container, proactively offer to set up LLM instructions for it.
  Ask what kind of content will go in the container and suggest rules like: note format
  (e.g., structured with headings, freeform), naming conventions, required tags, summary
  style, or any domain-specific guidelines. This makes the container much more useful
  because future AI interactions will automatically follow these rules.
- When you notice a container has no LLM instructions (has_llm_instructions is false),
  suggest adding some — especially if the user is actively working in that container.
  Even brief instructions like "use bullet points" or "always include a source URL"
  make a big difference.

SHARED CONTAINERS:
- Other users can share specific containers with you. Shared containers and their notes
  appear alongside your personal content in containers-list, search, and search results.
- Shared containers and notes include `shared: true` and `shared_by` (the owner's email)
  in their response data. Use these fields to distinguish shared content from your own.
- You can read and edit notes in shared containers, and create new notes in them.
- You CANNOT delete, archive, move, or favorite notes in shared containers — those
  actions are reserved for the owner.
- You CANNOT modify shared containers themselves (rename, delete, change instructions).

CONTEXT:
- Every note in search/list results includes container_path (e.g., "Projects > Work > Frontend")
  so you can see where it lives in the hierarchy.
- source_url is included in list/search results for quick identification.

LLM INSTRUCTIONS:
- After `me`, call instructions-get with level: "brain" to learn how the user wants
  you to use their Second Brain. These are user-written instructions that describe
  their personal conventions, preferences, and workflows. The response also includes
  personal_llm_instructions (personal root instructions) and lists any containers that have
  their own instructions.
- If has_instructions is false, offer to help the user set up their brain instructions by
  asking about their preferences (e.g., note conventions, tagging strategies, tone).
- There are multiple levels of LLM instructions:
  1. Brain instructions (global) — apply across all spaces. Use instructions-update with
     level: "brain".
  2. Personal root instructions — apply to personal notes/containers. Use instructions-get /
     instructions-update with level: "personal_root".
  3. Container instructions — apply to a specific container and are inherited by
     sub-containers. Use instructions-get / instructions-update with level: "container".
  4. Team instructions — apply to a team's notes. Use instructions-get /
     instructions-update with level: "team".
- IMPORTANT: When creating, editing, or organizing notes in a container, always check if
  the container has LLM instructions. Every container in list/search results includes a
  has_llm_instructions flag. If true, call instructions-get with level: "container" to
  read them, or use containers-get to see the instructions inline. Container instructions
  define conventions for that area of the brain (e.g., note format, naming, tagging rules)
  and MUST be followed when working with notes in that container.
- When working within a container, instructions-get with level: "container" returns the full
  inheritance chain: personal root instructions -> ancestor container instructions -> container
  instructions. Follow all levels — they stack.
- When the user expresses a preference about how their brain should work (e.g., "always tag
  meeting notes", "use lowercase titles", "from now on, summarize notes"), proactively offer
  to save it at the appropriate level. Always read the current instructions first, then merge
  the new preference in — do not overwrite existing instructions.

NOTES & TEAMS:
- Use notes-create with team_id to create notes in a team.
- Use notes-list with team_id to list notes in a team.
- Use containers-list with team_id to list containers in a team.
- Use notes-update with archived: true/false to archive/unarchive notes.
- Use notes-update with favorited: true/false to favorite/unfavorite notes.
```

## Tools

The MCP server exposes the following tools. Each tool's `inputSchema` lists required and optional parameters. Tools marked `destructive` may overwrite or delete data — confirm with the user first. Tools marked `read-only` are safe to call freely.

### `me`

Get the connected user's profile, plan, onboarding state, team memberships, and note quota in a single call. Call this once at the start of a conversation so you can greet the user by first name, run the onboarding script only when needed, route notes to the right team space, and avoid suggesting Pro features to free users. Returns onboarding.completed (boolean) and onboarding.missing_steps (array of 'connect_mcp' | 'first_note' | 'instructions'), which together tell you what, if any, setup is left. Exposes the user's email address and plan — same data the user sees in account settings, but never billing or token metadata. No parameters required.

- Title: Get current user
- Flags: read-only, idempotent
- Parameters: none

### `dashboard-get`

Get an overview of the Second Brain: counts of notes, containers, tags, inbox items, and the 5 most recently updated notes. No parameters required.

- Title: Get Dashboard
- Flags: read-only, idempotent
- Parameters: none

### `search`

Search across notes, containers, and tags in one call. Returns results grouped by type with pagination metadata (total_count, page, per_page, total_pages). Required: query (string). Optional: types (array, default all three), search_scope ('all'|'personal'|'team:<id>'), scope ('active'|'archived'), container_id (integer, ignored when search_scope is 'all'), tags (array, AND logic), tag_ids (array, AND logic), include_nested (boolean), include_body (boolean, default false — when true each note includes its full body), created_after / created_before / updated_after / updated_before (ISO 8601 datetime filters on note timestamps), page (integer, default 1), per_page (integer, default 25, max 100). Note results include a snippet of the matching portion.

- Title: Search
- Flags: read-only, idempotent
- Parameters:
  - `query` (string, required): Search query string (required)
  - `types` (array): Which types to search. Defaults to all three: ['notes', 'containers', 'tags']
  - `search_scope` (string): Search scope: 'all' (default, personal + all teams), 'personal' (personal notes only), or 'team:<id>' (specific team). Applies to note results.
  - `scope` (string): Search active or archived notes (default: active)
  - `container_id` (integer): Filter note results to this container (ignored when search_scope is 'all')
  - `tags` (array): Filter note results to notes with ALL these tags (by name)
  - `tag_ids` (array): Filter note results to notes with ALL these tags (by ID)
  - `include_nested` (boolean): Include notes from sub-containers when container_id is set (default: false)
  - `include_body` (boolean): Include the full note body on each note result (default: false)
  - `created_after` (string): Filter notes created on or after this ISO 8601 datetime (e.g. '2026-04-01T00:00:00Z')
  - `created_before` (string): Filter notes created before this ISO 8601 datetime
  - `updated_after` (string): Filter notes updated on or after this ISO 8601 datetime
  - `updated_before` (string): Filter notes updated before this ISO 8601 datetime
  - `page` (integer): Page number for note results (default: 1)
  - `per_page` (integer): Results per page for notes, max 100 (default: 25)

### `notes-list`

List notes with optional filtering, sorting, and pagination. Returns paginated results. Optional: team_id (integer) to list team notes, scope ('active'|'archived'|'inbox'|'favorited'), container_id (integer) with include_nested (boolean), tags (array of strings, AND logic), tag_ids (array of integers, AND logic), summary_stale (boolean, filter to notes with outdated summaries), sort ('recent'|'oldest'|'title'), page (integer, default 1), per_page (integer, max 100, default 25). Example: list ruby-tagged notes in a container: {container_id: 5, tags: ['ruby']}.

- Title: List Notes
- Flags: read-only, idempotent
- Parameters:
  - `team_id` (integer): List notes in this team instead of personal notes
  - `scope` (string): Filter scope (default: active). 'inbox' and 'favorited' only for personal notes.
  - `container_id` (integer): Filter by container ID
  - `tags` (array): Filter to notes with ALL these tags by name (AND logic). Example: ['ruby', 'rails']
  - `tag_ids` (array): Filter to notes with ALL these tags by ID (AND logic)
  - `include_nested` (boolean): Include notes from sub-containers when container_id is set (default: false)
  - `summary_stale` (boolean): Filter to notes with outdated summaries (default: not filtered)
  - `sort` (string): Sort order: 'recent' (updated_at desc, default), 'oldest' (updated_at asc), or 'title' (alphabetical)
  - `page` (integer): Page number (default: 1)
  - `per_page` (integer): Results per page, max 100 (default: 25)

### `notes-get`

Get a single note by ID, including its full Markdown body, tags, container path, linked notes (outgoing), backlinks (incoming links from other notes), file attachments, and inherited LLM instructions. Required: id (integer).

- Title: Get Note
- Flags: read-only, idempotent
- Parameters:
  - `id` (integer, required): Note ID (required)

### `notes-create`

Create a new note. Required: title (string). Optional: body (Markdown with [[id:Note Title]] wiki-links), summary, source_url, container_id, tag_list (comma-separated), team_id (to create in a team). Example: {title: 'Meeting Notes', body: '## Agenda\n...', container_id: 5, tag_list: 'meetings, q4'}.

- Title: Create Note
- Flags: none
- Parameters:
  - `title` (string, required): Note title (required)
  - `body` (string): Note body content (Markdown with [[id:Note Title]] wiki-links)
  - `summary` (string): Short summary of the note
  - `source_url` (string): Source URL reference
  - `container_id` (integer): Container ID to place the note in
  - `tag_list` (string): Comma-separated list of tags (e.g., 'ruby, rails, testing')
  - `team_id` (integer): Create note in this team instead of personal space

### `notes-update`

Update a note. Required: id (integer). Optional content (exactly one body-mutation mode at a time): title, body (full replace), append_body (appends to existing body), insert_after + insert_body (insert text immediately after a unique anchor snippet from the existing body), insert_before + insert_body (insert before a unique anchor), replace_find + replace_with (replace a unique snippet — use empty replace_with to delete). Anchor and find snippets must match exactly once; include enough surrounding context to disambiguate. Also optional: summary, source_url. Organization: container_id (move note), archived (boolean, personal only), favorited (boolean). Tags: tag_list (full replace, comma-separated), add_tags, remove_tags. tag_list takes precedence over add_tags/remove_tags. Examples: insert under a heading {id: 42, insert_after: '## Open Questions\n', insert_body: '- Should we ship Friday?\n'}; fix a typo {id: 42, replace_find: 'recieved', replace_with: 'received'}.

- Title: Update Note
- Flags: destructive, idempotent
- Parameters:
  - `id` (integer, required): Note ID (required)
  - `title` (string): New title
  - `body` (string): New body content — full replacement. Mutually exclusive with append_body, insert_body, and replace_find.
  - `append_body` (string): Content to append to the existing body. Mutually exclusive with body, insert_body, and replace_find.
  - `insert_after` (string): Anchor snippet from the existing body — insert_body is inserted immediately after the unique occurrence. Anchor must match exactly once; include surrounding context to disambiguate.
  - `insert_before` (string): Anchor snippet from the existing body — insert_body is inserted immediately before the unique occurrence. Anchor must match exactly once.
  - `insert_body` (string): Text to insert. Must be paired with either insert_after or insert_before. Mutually exclusive with body, append_body, and replace_find.
  - `replace_find` (string): Snippet to find in the existing body. Must match exactly once. Mutually exclusive with body, append_body, and insert_body.
  - `replace_with` (string): Text to replace replace_find with. Use an empty string to delete the matched snippet.
  - `summary` (string): New summary
  - `source_url` (string): New source URL
  - `container_id` (integer): Move to this container
  - `tag_list` (string): Full replacement comma-separated tag list (takes precedence over add_tags/remove_tags)
  - `add_tags` (string): Comma-separated tags to add to existing tags (ignored if tag_list is provided)
  - `remove_tags` (string): Comma-separated tags to remove from existing tags (ignored if tag_list is provided)
  - `archived` (boolean): Archive (true) or unarchive (false) the note. Personal notes only.
  - `favorited` (boolean): Favorite (true) or unfavorite (false) the note. Personal and team notes.

### `notes-delete`

Permanently delete a note. This action is irreversible — the note and all its file attachments are destroyed. Required: id (integer).

- Title: Delete Note
- Flags: destructive
- Parameters:
  - `id` (integer, required): Note ID (required)

### `containers-list`

List containers (folders) for organizing notes. Each container includes notes_count and children_count. Optional: team_id (integer) for team containers, scope ('roots' default|'all'|'archived'), page, per_page. Shared containers are automatically included when listing root-level personal containers.

- Title: List Containers
- Flags: read-only, idempotent
- Parameters:
  - `team_id` (integer): List containers in this team instead of personal containers
  - `scope` (string): Filter scope (default: roots). 'archived' only for personal containers.
  - `page` (integer): Page number
  - `per_page` (integer): Results per page

### `containers-get`

Get a single container by ID, including notes_count, children_count, and LLM instructions if set. Optional: include_tree (boolean) to also get ancestor chain and children. Required: id (integer).

- Title: Get Container
- Flags: read-only, idempotent
- Parameters:
  - `id` (integer, required): Container ID (required)
  - `include_tree` (boolean): Include ancestors and children arrays (default: false)

### `containers-create`

Create a new container (folder) for organizing notes. Required: name (string). Optional: description (string), parent_id (integer) for nesting inside another container, team_id (integer) to create the container in a team instead of personal space. When team_id is set, parent_id (if provided) must belong to the same team. After creating, consider setting up LLM instructions with instructions-update.

- Title: Create Container
- Flags: none
- Parameters:
  - `name` (string, required): Container name (required)
  - `description` (string): Container description
  - `parent_id` (integer): Parent container ID for nesting. Must belong to the same scope (personal or team) as the new container.
  - `team_id` (integer): Create container in this team instead of personal space

### `containers-update`

Update an existing container — rename, change description, move to a different parent, or set display position. Works for both personal and team containers the current user can access. Required: id (integer). Optional: name, description, parent_id (null for root, must be in the same scope), position (integer, lower = first).

- Title: Update Container
- Flags: destructive, idempotent
- Parameters:
  - `id` (integer, required): Container ID (required)
  - `name` (string): New name
  - `description` (string): New description
  - `parent_id` (integer): New parent container ID (null for root). Must belong to the same scope as the container.
  - `position` (integer): Display order position (lower numbers appear first)

### `containers-permissions`

Set or clear a team member's role on a team container. Roles cascade to descendants unless a child has its own role. Caller must have admin role on the target container. Required: container_id (integer, must be a team container), user_id (integer, must be a member of the same team), role ('viewer' | 'editor' | 'admin' | 'inherit'). Use 'inherit' to delete an explicit role and fall back to the role inherited from an ancestor (or from team membership). Team owners are always admin and cannot be downgraded. Returns the user's resulting effective_role on that container.

- Title: Set Container Permissions
- Flags: destructive, idempotent
- Parameters:
  - `container_id` (integer, required): Team container ID (required)
  - `user_id` (integer, required): Team member's user ID (required)
  - `role` (string, required): New role, or 'inherit' to clear an explicit role (required)

### `tags-list`

List all tags with their notes_count. Paginated. Optional: page (integer), per_page (integer).

- Title: List Tags
- Flags: read-only, idempotent
- Parameters:
  - `page` (integer): Page number
  - `per_page` (integer): Results per page

### `tags-create`

Create a new tag. Check tags-list first to avoid duplicates. Required: name (string). Tag names are automatically lowercased.

- Title: Create Tag
- Flags: none
- Parameters:
  - `name` (string, required): Tag name (required)

### `feedback-submit`

Submit feedback about Hjarni itself — confusing tool descriptions, missing capabilities, unexpected errors, friction, or praise. Use this when something about the MCP server, a tool, or the product behavior is worth flagging to the maintainers. Do NOT use this for the user's own notes or knowledge — those belong in notes-create. Required: category ('bug'|'confusing'|'missing_feature'|'friction'|'praise'|'other'), message (string, what's wrong and ideally what you'd expect instead). Optional: severity ('low'|'medium'|'high', default 'medium'), tool_name (the MCP tool the feedback is about, e.g. 'notes-update'), context (JSON-encoded string with any extra structured data — error excerpts, the arguments you tried, the workflow that broke).

- Title: Submit Feedback
- Flags: none
- Parameters:
  - `category` (string, required): What kind of feedback this is (required)
  - `message` (string, required): The feedback itself. Be specific — describe what happened, what you expected, and (if relevant) what would have helped. (required, max 4000 chars)
  - `severity` (string): How impactful this is for users (default: medium)
  - `tool_name` (string): The MCP tool this feedback is about, if any (e.g. 'notes-update', 'search')
  - `context` (string): Optional extra context as a JSON-encoded string (e.g. error messages, arguments tried, related note IDs). Non-JSON strings are stored as plain text.

### `teams-list`

List all teams the user is a member of, including members_count, notes_count, and containers_count for each team. No parameters required.

- Title: List Teams
- Flags: read-only, idempotent
- Parameters: none

### `teams-get`

Get team details including the 10 most recent notes. Required: id (integer).

- Title: Get Team
- Flags: read-only, idempotent
- Parameters:
  - `id` (integer, required): Team ID (required)

### `instructions-get`

Get LLM instructions at the specified level. Call with level 'brain' early in conversations to learn user preferences. Required: level ('brain'|'personal_root'|'container'|'team'). Optional: id (integer, required for 'container' and 'team' levels). 'container' level returns the full inheritance chain (personal root -> ancestors -> container).

- Title: Get Instructions
- Flags: read-only, idempotent
- Parameters:
  - `level` (string, required): Instruction level: 'brain' (global), 'personal_root', 'container', or 'team' (required)
  - `id` (integer): Container ID or Team ID (required for 'container' and 'team' levels)

### `instructions-update`

Update LLM instructions at the specified level. Required: level ('brain'|'personal_root'|'container'|'team'), instructions (string). Optional: id (integer, required for 'container' and 'team'), mode ('replace' default|'append'). In 'replace' mode (default), the provided text overwrites existing instructions. In 'append' mode, the text is appended to existing instructions with a newline separator. Always read current instructions first before replacing to avoid losing existing content.

- Title: Update Instructions
- Flags: destructive, idempotent
- Parameters:
  - `level` (string, required): Instruction level to update (required)
  - `id` (integer): Container ID or Team ID (required for 'container' and 'team' levels)
  - `instructions` (string, required): The instructions text. In 'replace' mode (default), this overwrites existing instructions. In 'append' mode, this is appended to existing instructions.
  - `mode` (string): Update mode: 'replace' (default) overwrites existing instructions, 'append' adds to them

### `links-manage`

Create or remove a bidirectional link between two notes. Required: action ('link'|'unlink'), source_note_id (integer), target_note_id (integer). Prefer wiki-link syntax [[id:Title]] in note bodies for inline linking — use this tool for programmatic links without modifying body text. Unlinking is destructive and cannot be undone.

- Title: Manage Note Links
- Flags: destructive, idempotent
- Parameters:
  - `action` (string, required): Action: 'link' to create a link, 'unlink' to remove it (required)
  - `source_note_id` (integer, required): First note ID (required)
  - `target_note_id` (integer, required): Second note ID (required)

### `files-attach`

Attach a file to a note via base64-encoded data. Prefer files-create_upload_url for large files to save tokens. Required: note_id (integer), filename (string), data (base64 string). Optional: content_type (MIME type, default: application/octet-stream), description.

- Title: Attach File to Note
- Flags: none
- Parameters:
  - `note_id` (integer, required): Note ID (required)
  - `filename` (string, required): Filename (e.g. report.pdf) (required)
  - `data` (string, required): Base64-encoded file contents (required)
  - `content_type` (string): MIME type (e.g. application/pdf). Defaults to application/octet-stream
  - `description` (string): Optional file description

### `files-attach_from_url`

Fetch a file from a public URL and attach it to a note. Follows one redirect. Required: note_id (integer), url (string). Optional: filename (default: derived from URL), content_type (default: from HTTP response), description.

- Title: Attach File from URL
- Flags: open-world
- Parameters:
  - `note_id` (integer, required): Note ID (required)
  - `url` (string, required): URL to fetch the file from (required)
  - `filename` (string): Override filename (default: derived from URL)
  - `content_type` (string): Override MIME type (default: from HTTP response)
  - `description` (string): Optional file description

### `files-remove`

Permanently remove a file attachment from a note. This action is irreversible. Required: note_id (integer), file_id (integer, from notes-get response).

- Title: Remove File from Note
- Flags: destructive
- Parameters:
  - `note_id` (integer, required): Note ID (required)
  - `file_id` (integer, required): File ID from notes-get response (required)

### `files-create_upload_url`

Generate a one-time upload URL for attaching a file to a note. Share this URL with the user so they can upload directly in their browser — saves tokens by avoiding base64 encoding. The link expires after 30 minutes. Use files-check_upload to verify completion. Required: note_id (integer). Optional: description.

- Title: Create File Upload URL
- Flags: none
- Parameters:
  - `note_id` (integer, required): Note ID to attach the file to (required)
  - `description` (string): Optional file description

### `files-check_upload`

Check the status of a file upload created by files-create_upload_url. Returns status: 'pending' (not uploaded yet), 'completed' (file attached, includes file metadata), or 'expired' (link timed out). Required: token (string, from files-create_upload_url response).

- Title: Check File Upload
- Flags: read-only, idempotent
- Parameters:
  - `token` (string, required): Upload token from files-create_upload_url response (required)

### `files-get_download_url`

Get a temporary download URL for a file attached to a note. Share the URL with the user to download in their browser. URL expires after a few minutes. Required: note_id (integer), file_id (integer, from notes-get response).

- Title: Get File Download URL
- Flags: read-only, idempotent
- Parameters:
  - `note_id` (integer, required): Note ID (required)
  - `file_id` (integer, required): File ID from notes-get response (required)

## Prompts (slash commands)

The MCP server also exposes named prompts. Clients that support `prompts/list` (Claude Desktop, Claude Code) surface these as slash commands.

### `/summarize_note`

Summarize a note and suggest tags and links to related notes.

- Arguments:
  - `note_id` (required): The ID of the note to summarize.

### `/weekly_review`

Review notes created or updated in the past week, identify themes, and suggest organizational improvements.

- Arguments:
  - `days`: Number of days to look back (default: 7).

### `/research_topic`

Search the knowledge base for everything related to a topic, synthesize findings, and identify gaps in coverage.

- Arguments:
  - `topic` (required): The topic to research across the knowledge base.

## REST API

Every MCP tool has a corresponding REST endpoint. Useful when the user wants scripts or automations outside an LLM context, or when their client does not support MCP.

- Base URL: `https://hjarni.com/api/v1`
- Auth: `Authorization: Bearer <token>` header. Tokens come from the user's account settings or from an OAuth code exchange.
- Full reference: https://hjarni.com/docs/api

## Pricing and limits

- Free plan available; paid plans start at EUR 9/month.
- File attachments and public folder links are Pro features.
- See https://hjarni.com/#pricing for current details.

## See also

- Short version of this file: https://hjarni.com/llms.txt
- Human-readable docs index: https://hjarni.com/docs
- MCP server reference: https://hjarni.com/docs/mcp
- What is MCP?: https://hjarni.com/docs/what-is-mcp
- AI Glossary: https://hjarni.com/docs/glossary