mcpbeat Sign in

Ainote MCP Server

by seunghan91 Your server? Claim it
answering

Ainote is answering right now. Last checked 5 min ago. 39 installs a week from npm. It exposes 35 tools.

Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.

The linked repository no longer exists on GitHub — it was deleted or made private.

Installs per day peak 21 · avg 6 · +81% w/w
a month agotoday
Uptime history 51 days of history · worst day 97%
51 days agonow
100.0%
Uptime 24h
91 of 91 checks
35
Tools
read from the server
428 ms
Response time
average over 24h
39
Installs / week
npm and PyPI

What changed 54

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 9 August 2026. No other catalogue keeps this.

8 Sep a tool description was rewritten sync_delete
18 Aug 2 tools changed the parameters they ask for sync_read, vault_sync
18 Aug a tool description was rewritten vault_sync
12 Aug 35 tools changed the parameters they ask for assumption_write, auth_key, delete_dev_doc and 32 more
11 Aug 6 tools changed the parameters they ask for env_sync_read, env_sync.secret_pull, env_sync_txn_push and 3 more
10 Aug 5 tools appeared assumption_write, judgment_list, judgment_submit and 2 more
10 Aug 3 tools changed the parameters they ask for handoff_save, vault_create, vault_read
9 Aug a tool changed the parameters it asks for handoff_save

What the code does

We have not read this server's code yet · tools taken from the live server

Capabilities

What this server is able to do. For an MCP server this is often the job itself — a terminal server runs commands because that is what it is for. Listed so you know what you are plugging in, not as an accusation.

Package points at a different repository seunghan91/ainote
пакет @ainote/mcp ссылается на ainote-dev/ainote-mcp

Is this your server and something here is wrong? Tell us — corrections are free and do not require a plan.

This code can reach further than it looks

We found places where it runs commands, builds paths or queries from values it is given. None of that is a flaw by itself — it becomes one when the code changes, and code changes quietly between releases. We re-read it on every one.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 5 min ago.

run in your terminal
claude mcp add ainote --transport http https://api.ainote.dev/api/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "ainote": {
      "url": "https://api.ainote.dev/api/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.ainote]
url = "https://api.ainote.dev/api/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "ainote": {
      "url": "https://api.ainote.dev/api/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "ainote": {
      "url": "https://api.ainote.dev/api/mcp"
    }
  }
}

This one needs environment variables set before it will start: AINOTE_API_KEY (64-character ainote MCP key. Issue one via `npx @ainote/mcp signup` (RFC 8628 device flow), or in a Claude session by calling signup_and_get_key, or at https://app.ainote.dev -> Settings -> MCP keys.). The author declared them in the registry entry; get the values from the project itself.

Available tools 35

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

env
env_sync.secret_pull
Pull an encrypted secret blob. Response is ciphertext_b64 only — server never sees and never returns plaintext.
env_sync.secret_push
Push a new client-encrypted secret. Ciphertext only — server never sees plaintext. Recipients must include the pushing device's own pubkey.
env_sync.secret_rotate
Rotate a secret: soft-delete the old node, create a new live node with the same alias and the new ciphertext+recipients. 7-day grace before hard delete of old ciphertext bytes.
env_sync_read
Read env-sync state. action: devices | drift | status | txn_pull. Secret reads are a separate tool (env_sync.secret_pull). (consolidated surface — same handlers as the legacy tools)
env_sync_txn_push
Ingest a batched envelope of client-recorded env_sync mutations. HLC-skew gated, partial-success on conflict.
env_sync_txn_rollback
Inverse-apply a prior env_sync transaction. Safety gates: ownership, idempotency, descendant-conflict (force opt-out).
env_sync_write
Non-destructive env-sync writes. action: enroll | request_share | heartbeat. Secret push/rotate are separate tools. (consolidated surface — same handlers as the legacy tools) Required per action — enroll: alias, age_pubkey, enrollment_token | request_share: target_device_id, secret_shares, device_id | heartbeat: device_id, installed_skills_hash, installed_hooks_hash.
sync
sync_audit_layer5
Record the result of a client-side Layer 5 codex review (sync.py merge gate) as a vault_events row. Body of the review is NOT stored — only an HMAC digest of the summary so operators can correlate without exposing review content. Opt-in: server skips writes (still returns success) unless ENV['AINOTE_LAYER5_AUDIT']='on' AND a versioned HMAC secret is configured. Used by the sync.py SessionStart hook + merge command to surface 'why was this blocked?' across multi-PC sessions.
sync_delete
Delete a file from the primary vault. Optional CAS via base_sha to detect concurrent multi-PC writes. Protected paths (global/memory/, global/skills/, global/planning/, global/intent/, global/claude-config/, handoffs/) require base_sha or explicit force:true (audited). Idempotent: deleting a non-existent path returns success with deleted:false.
sync_push
Push a markdown file into the primary vault. Optional CAS via base_sha to detect concurrent multi-PC writes (Layer 3 of multi-PC sync plan). WAF-bypass tip: large bodies (~10KB+) that get false-positive blocked at Cloudflare can be sent via `content_b64` (base64-encoded) OR `content` prefixed with `__B64__:` instead. When the push CREATES a new .md file, the response may carry `dedup_candidates` — existing memory files that look similar (keyword + title similarity, no LLM). It is an advisory, not a rejection: YOU decide to merge into one of them (re-push that path), drop this write as a duplicate (skip), or keep it as a new memory (store).
sync_push_batch
Push MANY files into the primary vault in ONE call. Use this instead of looping sync_push whenever you have more than a couple of changed paths — the cost of sync_push is round trips, not bytes. Per-item semantics are identical to sync_push (Layer 3 base_sha CAS, superseded contract, content_b64 WAF fallback). Partial success is normal and returns HTTP 200: read `results[]` and match entries by `path`, NOT by position. A conflict result always carries `remote_sha` + `conflict_reason` so you can go straight to sync_merge. Request-level failures (duplicate paths in one batch, idempotency key reused with a different payload, >200 items, >4MB) return 4xx and apply NOTHING. Each item MUST carry `content_sha` (SHA1 hex of the decoded body, same algorithm as git_sha) — it powers both the integrity check and the retry-safe `skipped_identical` result. Newly created .md items may carry `dedup_candidates` (same merge/skip/store advisory as sync_push); a batch creating more than 10 new files skips the check entirely and reports `dedup_skipped: "bulk"`.
sync_read
Read-only vault sync operations. action: list | pull | diff | merge | conflicts. Writes (push/delete) are separate tools — they carry CAS semantics. (consolidated surface — same handlers as the legacy tools) Required per action — diff: path | merge: path, base_text, local_text.
dev
delete_dev_doc
Soft-delete a dev document by title or UUID. Reversible from trash. Pass `category` when multiple docs share the same title across subcategories (memory/claude/cursor/env/docs).
dev_doc_write
Create or update a dev doc (non-destructive). action: create | update. Deletion is a separate tool (delete_dev_doc). (consolidated surface — same handlers as the legacy tools) Required per action — create: title, content | update: content.
dev_docs_read
Read dev docs. action: get | list | categories | pull (consolidated surface — same handlers as the legacy tools)
graph
graph_read
Read knowledge-graph nodes. action: get | list (consolidated surface — same handlers as the legacy tools)
graph_soft_delete
Soft-delete an env_sync graph node (sets deleted_at; .live scope hides it from reads). Idempotent — re-deleting a deleted node is a no-op success.
graph_write
Add or update a graph entity (non-destructive). action: add | update. Deletion is a separate tool (graph_soft_delete). (consolidated surface — same handlers as the legacy tools) Required per action — add: node_type, alias, payload, device_id | update: node_id, device_id, field_updates.
vault
vault_create
Create a new private vault as a GitHub repository under the user's account. Requires the user to have completed the GitHub App install flow first.
vault_read
Read vault metadata. action: list | clone | status (consolidated surface — same handlers as the legacy tools) Required per action — clone: name.
vault_sync
Wrapper around vault file sync. action=list|pull|push to work against the primary vault. list/pull are paginated — narrow with `path`/`since` and follow `next_cursor` instead of pulling the whole vault. For push: WAF-bypass via `content_b64` or `content: '__B64__:...'` prefix (mirrors sync_push).
handoff
handoff_read
Read session handoffs. action: get | list (consolidated surface — same handlers as the legacy tools) Required per action — get: project, topic.
handoff_save
Save a session handoff note for cross-device / cross-session continuation. Stored at handoffs/{project}-{topic}-{YYYY-MM-DD}.txt in the user's primary vault. Use the optional `time` param (HHMM, KST) to disambiguate multiple handoffs saved on the same day — it is appended to the topic slug (e.g. topic='phase-d', time='1555' → handoffs/{project}-phase-d-1555-{date}.txt).
judgment
judgment_list
List the authenticated user's own judgments (L3 layer) — use this to check your own blocking status (risk_tier 1 pending = execution blocked). Default order matches the /command queue: risk_tier ascending, then arrival order.
judgment_submit
Request a human judgment (L3 layer) by attaching evidence — approval, evidence, or verdict. This is the ONLY door an agent has into the judgment queue. 🔴 `decision` is REJECTED with an error if passed — judgments are always created with decision='pending'. Only a human decides them (from the /command queue). Use judgment_list afterwards to check whether this judgment has since been decided. risk_tier controls urgency: 1=destructive (blocks execution until decided), 2=reversible (may auto-proceed after a wait window), 3=informational (auto-expires after 24h).
project
project_read
List the authenticated user's projects (L2 intent layer), or fetch one by id. Each entry includes riskiest_assumption — the single highest-priority unverified assumption (or, if all are verified, the highest-criticality one).
project_write
Create or update a project (L2 intent layer). Omit `id` to create, pass it to update. There is no delete tool — use status: 'archived' to retire a project.
task
delete_task
Soft-delete a task by ID. Destructive but reversible within 30 days (TaskCleanupJob purges trash daily at 2am KST). Returns 404 if the task does not exist or is not owned by the authenticated user.
task_write
Create or update a task (non-destructive). action: create | update. Deletion is a separate tool (delete_task). (consolidated surface — same handlers as the legacy tools) Required per action — create: content | update: id.
assumption
assumption_write
Create or update an assumption under a project (L2 intent layer). Omit `id` to create, pass it to update. There is no delete tool. 🔴 `verdict` is REJECTED with an error if passed — verdict is confirmed only through a human judgment decision (see judgment_submit). This tool can only shape the assumption itself: what is being assumed, how critical it is, and what evidence would settle it.
auth
auth_key
Obtain an MCP key. action: login | signup (consolidated surface — same handlers as the legacy tools) Required per action — login: email, password | signup: email, password.
memory
memory_read
Read agent memory. action: get | search (consolidated surface — same handlers as the legacy tools) Required per action — get: source | search: query.
papers
list_papers
List notes/papers from AI Note. Supports keyword search across title and content, category filtering, pagination, and sorting. Returns id/title/content_preview/category_id/created_at. Use this when the user asks 'find my note about X', 'what did I write on Y', or wants to search their knowledge base.
setup
get_setup_guide
Get instructions for setting up AI Note MCP in Claude Desktop, Cursor, or other MCP clients. No authentication required.
tasks
tasks_read
Read tasks and task categories. action: tasks | categories (consolidated surface — same handlers as the legacy tools)

Tools removed

Tools this server used to expose. Anything built against them stopped working on the day they went.

create_dev_doc
removed 8 Aug 2026
create_task
removed 8 Aug 2026
env_sync.device_enroll
removed 8 Aug 2026
env_sync.device_list
removed 8 Aug 2026
env_sync.device_request_secret_share
removed 8 Aug 2026
env_sync.drift_status
removed 8 Aug 2026
env_sync.heartbeat_ping
removed 8 Aug 2026
env_sync.sync_status
removed 8 Aug 2026
env_sync_txn_pull
removed 8 Aug 2026
get_dev_doc
removed 8 Aug 2026
graph_add_entity
removed 8 Aug 2026
graph_get_node
removed 8 Aug 2026
graph_list_nodes
removed 8 Aug 2026
graph_update_entity
removed 8 Aug 2026
handoff_get
removed 8 Aug 2026
handoff_list
removed 8 Aug 2026
list_categories
removed 8 Aug 2026
list_dev_categories
removed 8 Aug 2026
list_dev_docs
removed 8 Aug 2026
list_tasks
removed 8 Aug 2026
login_and_get_key
removed 8 Aug 2026
memory_get
removed 8 Aug 2026
memory_search
removed 8 Aug 2026
pull_dev_docs
removed 8 Aug 2026
signup_and_get_key
removed 8 Aug 2026
sync_diff
removed 8 Aug 2026
sync_list
removed 8 Aug 2026
sync_merge
removed 8 Aug 2026
sync_pending_conflicts
removed 8 Aug 2026
sync_pull
removed 8 Aug 2026
update_dev_doc
removed 8 Aug 2026
update_task
removed 8 Aug 2026
vault_clone
removed 8 Aug 2026
vault_connect_status
removed 8 Aug 2026
vault_list
removed 8 Aug 2026

Endpoints

URLTransportStateLatencyChecked
https://api.ainote.dev/api/mcp streamable-http answering 662 ms 5 min ago

Alternatives to Ainote

same job, measured the same way
S
Open Agent Workspace · Public Notes
by chatgpt-tuned-drake-1114-execution-evidence-lab

Public agent notes, handoffs and replies. Hosted REST and MCP. No login, API key or payment.

3 tools answering
LLM Bus
by llm-bus

Coordinate multiple AI agents over MCP: atomic claims, leases, shared ledger, handoffs, tasks.

answering
Dart
by dartai

AI-native project management for tasks, docs, collaboration, and agents.

answering
Agentloopkit
by abhiyoheswaran1

Read-only MCP server for AgentLoopKit tasks, policies, reports, handoffs, and status.

52 installs/wk local only
Aigentify
by pooriaarab

Audit and generate agent-native product surfaces

42 installs/wk local only
Baseframelabs Catalogue
by abhiyoheswaran1

Agent-native catalogue of Baseframe Labs dev tools and MCP servers.

5 tools answering
MCP Curiosity Engine
by onetrueclaude-creator

Surface the notes you forgot you wrote — DMN replay for markdown vaults.

47 installs/wk local only
Agentlair
by piiiico

Give AI agents a real email address, vault, calendar, and task delegation via MCP.

31 installs/wk local only

Ainote — questions

Answers built from our own checks of this server.

What can Ainote do?
It exposes 35 tools, read directly from the server on our last check. Among them: assumption_write, auth_key, delete_dev_doc, delete_task, dev_docs_read, dev_doc_write and 29 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
What is Ainote mostly used for?
Its tools cluster around env, sync and vault. That is what this server is built to work with — the grouping comes from the actual tool names, not from a category we assigned.
Is Ainote working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 91 of 91 checks got a reply (100.0%), average response time 428 ms. The bar chart above shows every period we have measured.
Did Ainote ever remove tools?
Yes. create_dev_doc, create_task, env_sync.device_enroll, env_sync.device_list and 31 more are no longer exposed — we recorded the date each one disappeared. A tool vanishing usually means a breaking change for anything that depended on it.
Is Ainote still maintained?
The linked repository no longer exists on GitHub — it was deleted or made private. We show this because it changes what you can expect: an unmaintained server may keep answering for months and then stop without warning.
How do I connect Ainote?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Ainote need an API key?
No. Ainote completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 35 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Ainote?
It answers our handshake in 428 ms on average, which is faster than 37% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.
How many people use Ainote?
The npm package @ainote/mcp was installed 39 times in the last week. Week over week that is +81%. We show installs rather than GitHub stars on purpose: a star is a bookmark, an install is someone actually running it.