Vexa
Meeting bot and transcripts for Google Meet, Teams and Zoom. Live or after, speakers labelled.
作者による説明(英語の原文)
Review your AI agents' work in minutes, not hours of chat. Approve it or send it back.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
必要なもの
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
ウェブ、デスクトップ、モバイルのClaudeで使えます:
https://api.nodiom.md/mcpターミナルでこれを実行します
claude mcp add --transport http nodiom-cloud https://api.nodiom.md/mcpプロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"nodiom-cloud": {
"url": "https://api.nodiom.md/mcp"
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"nodiom-cloud": {
"type": "http",
"url": "https://api.nodiom.md/mcp"
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
ChatGPTがつなげるのは、インターネット上のサーバーだけです:
https://api.nodiom.md/mcpメニューの名前は、プランや時期によって少し違うことがあります。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
このサーバーは、ツール一覧を表示する前にサインインを求めます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月9日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント Synexiom-Labs で確認済みです
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
577ミリ秒で応答(HTTP 401)
OAuthでのサインインに対応しているため、AIアプリがログイン画面へ案内してくれます
まだチェックしていません。エンドポイントをチェックするときにツール一覧を読み取ります
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック3項目のうち3項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
作者のクラウドで動きます。インストール不要でインターネット経由でつながりますが、送った内容は作者のサーバーを通ります。
GitHubリポジトリの最終更新は–、最新バージョン(0.10.4)がレジストリに届いたのは22 日前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。URLでつながるので、リモートMCPサーバーに対応したアプリ(開発者モードのChatGPTなど)でも使えます。
同じカテゴリには:Vexa, emailmd, MCP WhatsApp Cloud
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:↓ 週あたりのダウンロードi★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
Meeting bot and transcripts for Google Meet, Teams and Zoom. Live or after, speakers labelled.
Render markdown into email-safe HTML, lint drafts for deliverability problems, and preview emails.
MCP server for WhatsApp Cloud API (Meta) — messages, media, and templates via Graph API
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
Structured reads and writes for Markdown.
Give AI agents a reliable way to work with the structure of your documents, without brittle string manipulation.
Nodiom reads and edits Markdown as a tree. Headings are branches; lists, paragraphs, tables and code blocks are nodes. You address them with path-like selectors, the way you'd query a DOM, and change one without rewriting, or breaking, the rest of the file.
| What it is | Where | |
|---|---|---|
| The library (this repo) | Structural read/write for Markdown in Node.js, on files or strings | npm install @synexiom-labs/nodiom |
| nodiom-mcp | An MCP server that gives AI agents these operations on your local Markdown files | Synexiom-Labs/nodiom-mcp |
| Nodiom Cloud | Hosted: shared state across agents and people. One board where AI agents hand in finished work and the people supervising them approve it or send it back | nodiom.md |
Structured state inside Markdown, here; shared state across agents and people, in Cloud. All three use the same engine and the same selectors.
When an AI agent, or any program, needs to change a Markdown document, it usually loads the whole file as a string, finds the right section with a regex, splices in new text, and hopes the formatting survived. Two writers at once, and one of them silently loses.
Nodiom treats Markdown as what it is: a tree. You say *where* (# Project > ## Tasks > li[contains="c_7f3a"]) and *what* (read, write, append, delete), and nothing outside that node changes.
import { Nodiom } from '@synexiom-labs/nodiom';
const doc = await Nodiom.fromFile('./project.md', { lock: true });
// Read everything under a heading (the heading line itself isn't included) const summary = doc.read('# Project > ## Summary');
// Add a task doc.append('# Project > ## Tasks', '- [ ] Deploy to staging');
// Tick it, addressed by its text rather than its position doc.write('# Project > ## Tasks > li[contains="Deploy to staging"]', '- [x] Deploy to staging');
// Remove the first finished item doc.delete('# Project > ## Done > li[0]');
// Write back to disk and release the lock await doc.save();
npm install @synexiom-labs/nodiom
Requirements: Node.js 18+
A selector is a " > "-separated path of segments, each matching a node in the document's structure.
"# Project Alpha" → The H1 "Project Alpha" and all its content
"## Tasks" → A top-level H2 named "Tasks" "# Project Alpha > ## Tasks" → The H2 "Tasks" nested under H1 "Project Alpha"
The number of # characters must match the heading's depth in the document.
Scope. "Content under ## Tasks" means everything after that heading until the next heading of the same or a higher level, which is how you'd read it.
Duplicate headings. If the same heading appears more than once in a scope, a bare segment is ambiguous and throws AmbiguousSelectorError; nodiom never silently picks the first. Qualify it with its parent heading, or address one by index, zero-based and negative-capable like li[n]:
"# Doc > ## Notes[0]" → The first "## Notes" under "# Doc"
"# Doc > ## Notes[1]" → The second "# Doc > ## Notes[-1]" → The last
The index must sit directly against the text. "## References [1]", with a space, is matched as a literal heading, and a heading that genuinely reads Tasks[1] is always tried literally first.
Frontmatter. A YAML (---) or TOML (+++) block at the top of a document is recognised as frontmatter. It never appears in tree(), can't be addressed by a selector, and is left byte-identical by every edit.
"## Tasks > li[0]" → First list item under ## Tasks
"## Tasks > li[-1]" → Last list item (negative indexing) "## Notes > p[0]" → First paragraph under ## Notes "## Arch > table[0]" → First table under ## Arch "## Arch > code[0]" → First code block under ## Arch
Element types: p, li, code, blockquote, table, hr.
An index is a position, not an identity. If another writer appends to the same section between the moment you compute li[2] and the moment you write to it, that index now points at a different node, and the write lands on the wrong one, silently.
Whenever more than one writer touches a document, address by content instead:
'## In Progress > li[contains="c_7f3a"]' → The list item whose text contains "c_7f3a"
"## Notes > p[contains='TODO']" → The paragraph containing "TODO"
The substring is matched against the node's own source text and must match exactly one node in scope. Matching several throws AmbiguousSelectorError rather than picking the first: silently editing one of several candidates is the failure this exists to prevent.
// From a file
const doc = await Nodiom.fromFile('./wiki.md');
// From a file, with an advisory lock (see Concurrency) const doc = await Nodiom.fromFile('./wiki.md', { lock: true, lockTimeout: 5000 });
// From a string: no filesystem, safe for serverless const doc = Nodiom.fromString(markdown);
// The Markdown under a selector. For a heading, its body without the heading
// line, so write(sel, read(sel)) changes nothing. const content: string = doc.read('# Project > ## Summary');
// Each list item's source under a selector, marker and nested lines included: // ['- [ ] Task A', '- [x] Task B\n - [x] sub-step'] const items: string[] = doc.readList('# Project > ## Tasks');
// Whether a location exists, and what it is const info = doc.query('# Project > ## Tasks'); // { exists: true, type: 'heading', depth: 2, childCount: 7, index: 3 }
// The heading outline const outline = doc.tree(); // [{ heading: 'Project', depth: 1, children: [{ heading: 'Tasks', depth: 2, children: [] }] }]
Mutations return this, so they chain.
// Replace the body of a section; the heading is kept
doc.write('# Project > ## Summary', 'On track for Q3.');
// Replace one list item. Text without its own bullet keeps the item's marker // and checkbox: this stays "- [ ] Final review (Friday)" doc.write('## Tasks > li[contains="Final review"]', 'Final review (Friday)');
// Add after the last node in a section, separated by a blank line doc.append('# Project > ## Tasks', '- [ ] Task C');
// Remove a node, or a heading together with its whole section doc.delete('# Project > ## Done > li[0]');
doc .append('# Project > ## Tasks', '- [ ] Task D') .delete('# Project > ## Done > li[-1]');
Your content is inserted as written (only trimmed), never re-serialized, and everything you didn't address is left byte-for-byte as it was.
const markdown: string = doc.toString();
await doc.save(); // write back to the original file, release any lock await doc.saveAs('./out.md'); // write to a new file (keeps the original lock) await doc.unlock(); // release the lock explicitly
import {
NodiomError, // base class of the errors below SelectorNotFoundError, // nothing matched; .suggestions has near misses SelectorParseError, // the selector itself is malformed AmbiguousSelectorError, // more than one node matched LockError, // couldn't get the file lock in time } from '@synexiom-labs/nodiom';
try { doc.read('# Project > ## Taks'); // typo } catch (e) { if (e instanceof SelectorNotFoundError) { console.log(e.selector); // "# Project > ## Taks" console.log(e.suggestions); // ["Tasks"] } }
A structural editor is only useful if it doesn't damage what it doesn't touch. Nodiom edits the source text at the node's exact position rather than re-printing the document, so formatting, spacing, list markers and escaping outside the edited node stay as they were. On a sample of 2,369 real-world Markdown files (an early user's own notes), every file round-trips byte-identically.
nodiom-mcp exposes these operations as MCP tools (nodiom_tree, nodiom_read, nodiom_read_list, nodiom_query, nodiom_write, nodiom_append, nodiom_delete) for Claude Code, Claude Desktop, Cursor or any MCP client, on Markdown files on your disk.
claude mcp add -s user nodiom -- npx -y @synexiom-labs/nodiom-mcp
When agents run on different machines, or come from different vendors, they need one place to share state. Nodiom Cloud is that place, built on this engine:
Connect from Claude, ChatGPT, Cursor or VS Code by adding one address and signing in, with no key to copy:
https://api.nodiom.md/mcp
There's a free plan. Setup for each app is at nodiom.md, and the full tool reference is in the docs.
On one machine, nodiom takes an advisory file lock via proper-lockfile. fromFile acquires the lock *before* reading, so two processes can't both read the old version and overwrite each other.
const doc = await Nodiom.fromFile('./shared-wiki.md', { lock: true });
// Other nodiom processes locking this file wait, or throw LockError after lockTimeout
doc.append('## Log', - ${new Date().toISOString()} Agent B finished the task); await doc.save(); // writes and releases the lock
The lock covers Node.js processes on the same machine. Across machines or serverless functions, use Nodiom Cloud, where every write runs under a database row lock on the document.
| Approach | Structured reads? | Structural writes? | Round-trip fidelity | Serverless | Concurrent |
|---|---|---|---|---|---|
fs.readFile + regex | No | Fragile | Depends on the regex | No | No |
gray-matter | Frontmatter only | Frontmatter only | Yes | Yes | No |
| Databases | No | No | No (loses the Markdown) | Yes | Yes |
| Vector DBs | Semantic only | No | No | Yes | Yes |
| nodiom | Yes | Yes | Yes | Yes (fromString) | Same machine |
| Nodiom Cloud | Yes | Yes | Yes | Yes | Across machines |
Planned, in no fixed order:
insert() with positional control: before or after a sibling node.diff(): a structural diff between two versions of a document.## *Tasks*).冒頭だけを表示しています。続きはリポジトリで読めます