Skip to main content
Glama
mrsunglasses-experiments

hedgedoc-mcp

by mrsunglasses-experiments
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

hedgedoc-mcp

An MCP server that lets AI agents — Claude Code, Codex, Cursor, VS Code, OpenCode, Pi, or any other MCP client — read and write notes on a self-hosted HedgeDoc 1.x instance.

HedgeDoc 1.x has no API token system, so this server handles the real auth model (session cookies from email/password login) and exposes it as a clean, agent-friendly toolset.

Why this exists

HedgeDoc is a great self-hosted, open-source, collaborative markdown editor. But if you want an AI agent to write notes to it programmatically, you hit a wall immediately: HedgeDoc 1.x has no API tokens. Every write endpoint (POST /new, etc.) requires an authenticated browser-style session, tracked via the Express session cookie configured by the instance (normally connect.sid).

This project does the unglamorous work of handling that correctly — login, cookie storage, automatic re-authentication on expiry — and wraps it in an MCP server so any agent can just call hedgedoc_create_note and not think about any of it.

Related MCP server: Joplin Server MCP

Features

  • 🔐 Handles HedgeDoc 1.x's real auth model (session cookies, not tokens)

  • 🔁 Auto re-login on session expiry — no manual cookie refresh needed

  • 🛠️ 5 MCP tools: create, read, info, whoami, history

  • 🐍 Standalone Python client (hedgedoc_mcp.client.HedgeDocClient) usable outside MCP too

  • ✅ Fully tested — against an in-process fake HedgeDoc server; no live instance required

  • 📦 Works with any MCP client — setup guides for 20+ agents: Claude Code, Codex, Cursor, VS Code, OpenCode, Pi, Gemini CLI, Goose, Zed, and more

Quick start

1. Install uv

Your agent starts the server for you with uvx, which downloads and caches hedgedoc-mcp from PyPI on first use. You only need uv installed:

curl -LsSf https://astral.sh/uv/install.sh | sh     # macOS / Linux
# Windows: powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

You don't run uvx hedgedoc-mcp yourself: it's a stdio server, so it just waits for an agent to talk to it.

uv tool install hedgedoc-mcp     # persistent install; point your agent at the `hedgedoc-mcp` executable
pip install hedgedoc-mcp          # into an existing environment

# Unreleased changes from the main branch:
uvx --from git+https://github.com/mrsunglasses-experiments/hedgedoc-mcp hedgedoc-mcp

2. Choose your credentials

The server is configured entirely through environment variables:

Variable

Required

Description

HEDGEDOC_URL

Yes

Your instance's URL as shown in the browser, e.g. https://md.example.com

HEDGEDOC_EMAIL + HEDGEDOC_PASSWORD

One of these two options

Email/password login. The server logs in on first use and again whenever the session expires.

HEDGEDOC_SESSION_COOKIE

One of these two options

A session cookie from hedgedoc-mcp-login (below). Saves a login round-trip; when it expires, the server falls back to email/password if those are set.

HEDGEDOC_SESSION_COOKIE_NAME

No

Only if your instance uses a session cookie name other than connect.sid

Recommended: set HEDGEDOC_EMAIL and HEDGEDOC_PASSWORD. That's all you need, and you never have to refresh anything. Email login must be enabled on the instance (CMD_EMAIL=true, the default).

Set these in your agent's MCP config (step 3), not just in your shell. Most agents start MCP servers with a minimal environment, so variables you export usually don't reach the server.

uvx --from hedgedoc-mcp hedgedoc-mcp-login --url https://md.example.com --email you@example.com

It prompts for your password (or reads HEDGEDOC_PASSWORD; avoid --password, which lands in your shell history) and prints HEDGEDOC_SESSION_COOKIE=... for your agent's config. With --write-env .env, it also saves the value to a file readable only by you. The server doesn't read .env files itself.

3. Connect your agent

For Claude Code:

claude mcp add hedgedoc --scope user \
  -e HEDGEDOC_URL=https://md.example.com \
  -e HEDGEDOC_EMAIL=you@example.com \
  -e HEDGEDOC_PASSWORD='your-password' \
  -- uvx hedgedoc-mcp

Most other agents take the same three pieces of information: command uvx, argument hedgedoc-mcp, and the environment variables above. Config files and formats differ, though. docs/CLIENTS.md has a ready-to-paste config for each of these clients:

Terminal agents

Claude Code · Codex CLI · Gemini CLI · GitHub Copilot CLI · OpenCode · Pi · Amp · Goose · Crush · Hermes Agent · Factory Droid · Qwen Code · Devin CLI

Editors and IDEs

Cursor · VS Code (Copilot) · Devin Desktop (Windsurf) · Zed · JetBrains · Cline · Kilo Code · Continue · Kiro

Desktop apps

Claude Desktop · ChatGPT desktop · Warp · LM Studio

The guide also covers keeping passwords out of config files that get committed, plus troubleshooting.

4. Try it

Ask your agent something like "Create a HedgeDoc note summarizing this conversation" or "Which HedgeDoc account are you logged in as?". If the tools don't show up, check the setup with MCP Inspector, which runs the server outside any agent.

Available tools

Tool

Description

hedgedoc_create_note

Create a new note (optionally with a custom URL alias). Returns the note ID and URL.

hedgedoc_read_note

Fetch a note's raw markdown content by ID or alias.

hedgedoc_note_info

Get a note's title, description, view count, and timestamps.

hedgedoc_whoami

Verify the session is valid and show the logged-in user.

hedgedoc_list_history

List the logged-in user's recently viewed/pinned notes.

There is no update tool: HedgeDoc 1.x has no HTTP endpoint for editing a note (see Known limitations), so write a note's full content when creating it.

Using the Python client directly

You don't need MCP to use this — the underlying client is a normal Python class:

from hedgedoc_mcp.client import HedgeDocClient

client = HedgeDocClient("https://md.example.com")
client.login(email="you@example.com", password="your-password")

result = client.create_note("# Research notes\n\nSome findings...")
print(result.url)

content = client.read_note(result.note_id)
info = client.note_info(result.note_id)

Known limitations

HedgeDoc 1.x's HTTP API is genuinely limited compared to newer forks — see docs/LIMITATIONS.md for the full rundown, including:

  • No API tokens (session-cookie auth only)

  • No HTTP note-update endpoint

  • No delete endpoint over HTTP

These are constraints of the HedgeDoc 1.x server itself, not this client — the docs explain the workarounds this project uses and what genuinely isn't possible.

Development

git clone https://github.com/mrsunglasses-experiments/hedgedoc-mcp.git
cd hedgedoc-mcp
uv venv && source .venv/bin/activate
uv pip install -e ".[dev]"

pytest                 # run tests (against an in-process fake HedgeDoc; no live server needed)
ruff check .            # lint
ruff format --check .   # formatting

See docs/ARCHITECTURE.md for how the auth flow and MCP layer fit together, and CONTRIBUTING.md for contribution guidelines.

License

MIT — see LICENSE.

Available Tools

5 tools
hedgedoc_create_noteA

Create a new note on the HedgeDoc instance.

Returns JSON with two fields: 'note_id' (the unique identifier / URL slug) and 'url' (the full URL where the note can be viewed or shared). Use alias to assign a human-readable slug such as 'q3-research-notes'. Notes cannot be edited afterwards: HedgeDoc 1.x has no HTTP endpoint for updating note content, so write the complete content in one call. Alias support requires FreeURL mode enabled on the server (CMD_ALLOW_FREEURL=true).

ParametersJSON Schema
NameRequiredDescriptionDefault
aliasNoOptional custom URL slug, e.g. 'meeting-2026-08-16' or 'q3-research'. Must be URL-safe (letters, digits, hyphens). Requires FreeURL mode on the server.
contentYesFull markdown content for the note. Supports standard CommonMark plus HedgeDoc extensions (diagrams, math, front matter, etc.).

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the write/non-idempotent/open-world profile; the description adds the non-obvious consequences: notes are immutable after creation (HedgeDoc 1.x has no update HTTP endpoint) and alias creation depends on a server config flag. It also discloses the response shape, which the annotations do not cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then return fields, then the two caveats, which is good ordering. It loses a point for restating the alias/FreeURL constraint that the schema already carries and for running somewhat long with six sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description compensates by enumerating the returned fields (note_id, url). Combined with the immutability warning and the alias prerequisite, an agent has everything required to call this correctly in one shot.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% – both parameters already document their type, format, and the FreeURL requirement. The description's 'human-readable slug such as q3-research-notes' is only a marginal addition over the schema's own example, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Create a new note on the HedgeDoc instance.' All four siblings (read_note, note_info, whoami, list_history) are read operations, so the write verb alone separates this tool cleanly from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives operative context: content must be complete in one call because there is no update endpoint, and the alias feature requires FreeURL mode server-side. It does not name a sibling alternative or state when not to use the tool, but for a create-only API the guidance an agent needs is present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hedgedoc_list_historyA
Read-only

List the logged-in user's recently viewed and pinned notes.

Returns a JSON array of note objects. Each object includes: 'id' (note ID or alias), 'text' (note title), 'tags' (array of strings), 'pinned' (boolean), and 'time' (last-viewed timestamp in milliseconds). Requires a valid session — returns an error if not authenticated.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavior: it requires a valid session and returns an error if unauthenticated, plus it documents the returned fields since no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The action statement is front-loaded in one sentence, and the return-shape detail that follows earns its place because no output schema is defined. No filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no output schema, the description supplies everything needed: what is listed, the return structure and field types, and the auth prerequisite. Nothing an agent needs to invoke it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 — there is no parameter semantics to explain and the description correctly does not invent any. Nothing is missing on this dimension.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List), resource (recently viewed and pinned notes), and a clear owner scope (the logged-in user's). The scope wording implicitly separates it from siblings like hedgedoc_note_info and hedgedoc_read_note, which operate on a specific note rather than the user's history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the phrase 'recently viewed and pinned notes' — an agent can infer this is the history lookup — but the description never states when to prefer it over siblings or any exclusions. No explicit when-to-use routing is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hedgedoc_note_infoA
Read-only

Get metadata for a note.

Returns JSON with: 'title' (string), 'description' (string or null), 'viewcount' (integer — total views), 'createtime' and 'updatetime' (ISO 8601 timestamps, e.g. '2026-08-16T10:30:00.000Z'). Public notes need no authentication.

ParametersJSON Schema
NameRequiredDescriptionDefault
note_idYesThe note's unique ID (e.g. 'AbC123XyZ') or custom alias (e.g. 'my-meeting-notes'). Both forms are accepted.

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: the exact JSON fields returned (title, description, viewcount, createtime, updatetime) and the authentication requirement for non-public notes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in one short sentence, followed by the return-field enumeration and the auth note. The field list is somewhat verbose but earns its place because no output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly carries the return-value burden by enumerating all fields and their types. Combined with annotations covering read-only behavior and the auth note for private notes, an agent has what it needs to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains that both a unique ID and a custom alias are accepted. The description adds no parameter detail beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get metadata for a note'), which is clearly distinct from hedgedoc_read_note (content) and hedgedoc_create_note. It does not explicitly name or contrast with those siblings, but the resource scope makes the distinction inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus hedgedoc_read_note or hedgedoc_list_history. The only contextual cue is 'Public notes need no authentication,' which hints at a permission condition but gives no selection guidance or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hedgedoc_read_noteA
Read-only

Fetch the raw markdown content of an existing note by its ID or alias.

Returns the note's markdown as a plain string. Public notes can be read without authentication; private ones need the configured account's access.

ParametersJSON Schema
NameRequiredDescriptionDefault
note_idYesThe note's unique ID (e.g. 'AbC123XyZ') or custom alias (e.g. 'my-meeting-notes'). Both forms are accepted.

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely new behavioral context: the auth requirement split between public and private notes, and the return shape (a plain markdown string). Rate limits and failure modes for nonexistent IDs are not addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and resource, then two compact supporting sentences covering return type and access rules. No filler or redundancy; every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with no output schema, the description supplies what annotations and schema leave open: the access model and a plain-string return. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single note_id parameter already documents both the ID and alias forms with examples. The description's mention of 'ID or alias' merely echoes the schema, adding no syntax or format detail beyond it, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fetch the raw markdown content of an existing note') and a scoping key ('by its ID or alias'). The 'raw markdown' framing implicitly separates it from hedgedoc_note_info's metadata role, but no sibling is named explicitly, so it falls short of the highest bar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an applicability condition for authentication ('public notes can be read without authentication; private ones need the configured account's access'), which is useful context. However, it never says when to choose this tool over hedgedoc_note_info or hedgedoc_create_note, leaving alternative routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hedgedoc_whoamiA
Read-only

Verify the current session is valid and return the logged-in user's profile.

Returns JSON with user info (status, id, name, photo). Call this to confirm the server is correctly authenticated before attempting write operations, or to identify which account is active.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: the call doubles as an authentication health check before writes, and it returns JSON with status/id/name/photo. It stops short of describing failure behavior for an invalid session.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action in the first sentence, then adds return shape and usage guidance. Every sentence earns its place, though the 'confirm the server is correctly authenticated' phrasing overlaps slightly with 'Verify the current session is valid' in the opening line.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description does the right thing by summarizing the return payload (status, id, name, photo), which an agent needs to consume the result. It is nearly complete for a zero-parameter read tool; only the invalid-session/error path is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the calibration baseline a 4 applies. The description correctly implies no inputs are needed by framing this as a session check, and there are no parameter semantics to specify.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource pair ('Verify the current session', 'return the logged-in user's profile') and is clearly distinct from the note-oriented siblings (create_note, read_note, note_info, list_history). An agent can identify this as the authentication/identity probe without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names two trigger conditions: 'confirm the server is correctly authenticated before attempting write operations' and 'identify which account is active'. That is strong when-to-use guidance, though it does not state any when-not condition or name an alternative tool for the same goal, which is why it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv0.2.0
    • Changedhedgedoc_create_note7 fields changed
      • addedInput schema / properties / alias / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / alias / default
        Added value: +null
      • changedInput schema / properties / alias / description
        Previous value: -"Optional custom URL slug, e.g. 'meeting-2026-08-16' or 'q3-research'. Must be URL-safe (letters, digits, hyphens). Required if you intend to update this note later. Requires FreeURL mode on the server."New value: +"Optional custom URL slug, e.g. 'meeting-2026-08-16' or 'q3-research'. Must be URL-safe (letters, digits, hyphens). Requires FreeURL mode on the server."
      • addedInput schema / properties / alias / title
        Added value: +"Alias"
      • removedInput schema / properties / alias / type
        Removed value: -"string"
      • addedInput schema / properties / content / title
        Added value: +"Content"
      • addedInput schema / title
        Added value: +"hedgedoc_create_noteArguments"
    • Changedhedgedoc_list_history1 field changed
      • addedInput schema / title
        Added value: +"hedgedoc_list_historyArguments"
    • Changedhedgedoc_note_info3 fields changed
      • changedInput schema / properties / note_id / description
        Previous value: -"Note ID or alias."New value: +"The note's unique ID (e.g. 'AbC123XyZ') or custom alias (e.g. 'my-meeting-notes'). Both forms are accepted."
      • addedInput schema / properties / note_id / title
        Added value: +"Note Id"
      • addedInput schema / title
        Added value: +"hedgedoc_note_infoArguments"
    • Changedhedgedoc_read_note2 fields changed
      • addedInput schema / properties / note_id / title
        Added value: +"Note Id"
      • addedInput schema / title
        Added value: +"hedgedoc_read_noteArguments"
    • Removedhedgedoc_update_note
    • Changedhedgedoc_whoami1 field changed
      • addedInput schema / title
        Added value: +"hedgedoc_whoamiArguments"
  2. 6 tool updatesv0.1.0
    • First observedhedgedoc_create_note
    • First observedhedgedoc_list_history
    • First observedhedgedoc_note_info
    • First observedhedgedoc_read_note
    • First observedhedgedoc_update_note
    • First observedhedgedoc_whoami
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: create content, read content, inspect metadata, verify authentication, and list history. The only potential overlap is read_note vs note_info, but the descriptions clearly separate raw markdown retrieval from metadata fields. No two tools could be reasonably confused.

Naming Consistency4/5

All names share a consistent hedgedoc_ prefix and mostly follow a verb_noun pattern (create_note, read_note, list_history). Minor deviations are note_info (noun_info) and whoami (bare verb), which break the pattern but remain unambiguous. Overall predictable and readable.

Tool Count4/5

Five tools is slightly thin but reasonable for a read-centric HedgeDoc integration whose API lacks an update endpoint. Each tool earns its place: create, read, metadata, auth check, and history. It is a bit under-scoped for fuller note management but not problematically so.

Completeness3/5

The surface covers create, read, and metadata, plus auth and history, but has no delete operation and no way to update content (the latter is a documented API limitation). Listing only recently viewed/pinned notes rather than a full note listing is also a gap. Notable lifecycle operations are missing, though some are impossible via the HedgeDoc 1.x API.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers