Skip to main content
Glama
iwaohig

LINE WORKS AiNote (unofficial)

by iwaohig
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

lineworks-ainote-mcp

Unofficial community project. This is a personal, read-only MCP server for LINE WORKS AiNote (AI meeting notes). It is not an official LINE WORKS product and is not affiliated with, endorsed by, or supported by LINE WORKS Corp. Provided as-is under the MIT License.

It lets Claude (or any MCP client) list, search, and read AiNote summaries and transcripts. LINE WORKS also offers an official WORKS MCP for mail, calendar, and tasks; AiNote is not part of it as of September 2026, so this project is meant to be used alongside it, not instead of it. Documentation below is in Japanese. See Support for what is and is not covered here.

LINE WORKS AiNote (AI議事録) のノートを Claude から参照するための MCP サーバーです。読み取り専用。 個人が公開している非公式の実装で、LINE WORKS の公式製品・公式サポートの対象ではありません。 公式の WORKS MCP (メール・カレンダー・タスク) には 2026 年 9 月時点で AiNote が含まれていないため、 その補完として併用する想定です。

入口

内容

MCP サーバーとして使う

このリポジトリの ainote_mcp.py (以下の手順)

API を直接試す

Open In Colab notebooks/lineworks_ainote_api.ipynb

解説記事 (Qiita):

ツール

内容

list_notes

ノート一覧 (タイトル・作成日時・音声長のみ)

search_notes

キーワード検索 (同上)

get_note_summary

AI 要約と参加者 (文字起こしを含まない)

get_note_transcript

文字起こし全文 ([時刻] 話者: 発言 に整形)

前提

  • LINE WORKS で AiNote が利用でき、Developer Console でスコープ ainote.read を選べること

  • Python 3.12 以上と uv

  • Claude Desktop または Claude Code

Related MCP server: LogicNotes MCP Server

セットアップ

1. Developer Console でアプリを作る

  1. LINE WORKS Developer Console でアプリを新規追加

  2. OAuth Scopes に ainote.read を追加

  3. Redirect URL に http://localhost:8765/callback を登録 (完全一致が必要)

  4. Client ID と Client Secret を控える

2. 初回ログイン

uv run ainote_mcp.py auth

Client ID / Client Secret を入力するとブラウザが開きます。LINE WORKS にログインして許可してください。 トークンは OS の資格情報ストア (Windows: 資格情報マネージャー、macOS: キーチェーン) に保存されます。 設定ファイルや環境変数にシークレットを書く必要はありません。

3. Claude に登録

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "lineworks-ainote": {
      "command": "uv",
      "args": ["run", "--quiet", "C:\\path\\to\\ainote_mcp.py"]
    }
  }
}

PyPI からインストールする場合 (uvx)

リポジトリを clone せずに使う場合は PyPI のパッケージ lineworks-ainote-mcp を uvx で起動できます。 初回ログインは uvx lineworks-ainote-mcp auth、ログアウトは uvx lineworks-ainote-mcp logout です。

{
  "mcpServers": {
    "lineworks-ainote": {
      "command": "uvx",
      "args": ["lineworks-ainote-mcp"]
    }
  }
}

Claude Code の場合:

claude mcp add -s user lineworks-ainote -- uvx lineworks-ainote-mcp

Windows で uv が見つからない場合は command にフルパスを書いてください。

Claude Code:

claude mcp add lineworks-ainote -- uv run --quiet /path/to/ainote_mcp.py

ログアウト

uv run ainote_mcp.py logout

保存済みの Client ID / Secret / トークンをすべて削除します。

制限

  • AiNote API は User Account 認証専用です。Service Account (JWT) では利用できません

  • 検索 API の呼び出し上限は 60 回/分です。ツール側で 1 秒間隔に制限しています

  • 削除 API と統計系 API (管理者権限が必要) は実装していません

  • 管理者による利用制御やマスキングはありません。どのノートを Claude に読ませるかは利用者の判断になります

動作確認環境

  • Windows 11 (資格情報マネージャー) で確認済み

  • macOS はキーチェーンで動く設計ですが未確認です

  • Linux / WSL では keyring のバックエンド (Secret Service など) が必要です。 ない環境では起動時にエラーになります。keyrings.alt を入れると動きますが平文保存になります

Support / サポートについて

English

  • This project is provided as-is under the MIT License, with no warranty and no guaranteed response time. It is maintained in a personal capacity.

  • Issues and pull requests are welcome for problems in this MCP server itself: setup, the authentication flow, tool behavior, and documentation.

  • Problems with the AiNote service or the LINE WORKS API (API errors, scopes not available in your Developer Console, summaries not being generated, plan eligibility) are outside the scope of this project. Please refer to the LINE WORKS Developers documentation and the official LINE WORKS support channels.

  • Answers in issues are based on the public LINE WORKS Developers documentation and on behavior observed on a production tenant. They are not official statements about the product.

  • If this project stops being maintained, the repository will be archived and a notice added here.

日本語

  • 本プロジェクトは MIT ライセンスで現状のまま提供します。保証や応答期限はなく、個人として保守しています

  • Issue / Pull Request はこの MCP サーバー自体の問題 (セットアップ、認証フロー、ツールの挙動、 ドキュメント) について受け付けます

  • AiNote や LINE WORKS API 側の問題 (API エラー、Developer Console でスコープが選べない、 要約が生成されない、プランの対応状況) は本プロジェクトの範囲外です。 LINE WORKS Developers のドキュメントと LINE WORKS の公式サポート窓口をご利用ください

  • Issue での回答は公開ドキュメントと製品テナントでの動作確認に基づくもので、 製品についての公式な見解ではありません

  • メンテナンスを終了する場合はリポジトリをアーカイブし、ここに記載します

Available Tools

4 tools
get_note_summaryA

ノートの AI 要約と参加者を取得する。文字起こし全文は含まない。

ノートの内容を知りたい場合はまずこれを使う。要約で足りない場合にのみ
get_note_transcript で全文を取得する。transcriptBlocks は文字起こしの
発言ブロック数で、全文を取る際の max_blocks の目安になる。

要約はノートの作成者が AiNote 上でテンプレートを選んで生成するもの。
summaries が空の場合は作成者が要約を生成していないので、内容を知るには
get_note_transcript で全文を読む。

Args:
    note_id: ノートID。list_notes または search_notes の結果から得る。
ParametersJSON Schema
NameRequiredDescriptionDefault
note_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden. It discloses that the tool returns only summary/participants, not the transcript, and that summaries may be empty depending on whether the creator generated them. It also explains transcriptBlocks as a hint for max_blocks. It doesn't mention idempotency or rate limits, but for a read-only lookup these are less critical. It adds meaningful behavioral context beyond the schema.

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 description is organized into short paragraphs: purpose, usage routing, caveat about empty summaries, and an Args block. Every sentence contributes to correct selection or invocation, with no fluff. It's slightly longer than average but justified by the routing and fallback logic.

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?

The tool has an output schema, so return fields are documented elsewhere. The description covers the essential contextual caveats: when summaries might be empty, when to switch to get_note_transcript, and how transcriptBlocks relates to the transcript tool. For a one-parameter get operation, this is sufficiently complete.

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 input schema gives no description for note_id (0% coverage), but the description compensates by stating that note_id is obtained from the results of list_notes or search_notes. This gives the agent a reliable source for the parameter value. It doesn't specify format, but the provenance hint is valuable and actionable.

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?

The description begins with a specific verb and resource: 'get the AI summary and participants of a note.' It explicitly states what is not included (full transcript), distinguishing it from the sibling get_note_transcript. An agent can immediately tell this tool's purpose apart from its siblings.

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

Usage Guidelines5/5

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

The description gives explicit routing: use this first to know note content, and only call get_note_transcript when the summary is insufficient. It also explains that if summaries is empty, the transcript is the fallback. This is textbook when-to-use/when-not-to-use guidance.

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

get_note_transcriptA

ノートの文字起こし全文を取得する。

1 時間の会議で数十 KB になる。要約で足りる場合は get_note_summary を使うこと。
発言は `[時刻] 話者: 発言` の形に整形して返す。

Args:
    note_id: ノートID。
    max_blocks: 返す発言ブロックの上限。省略すると全件。
ParametersJSON Schema
NameRequiredDescriptionDefault
note_idYes
max_blocksNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It discloses the output format '`[時刻] 話者: 発言`' and the size implication, plus the default behavior of max_blocks (omitted returns all). It does not cover error handling or side effects, but this is a read-only operation and the key behavioral traits are stated.

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 description is concise and well-structured: a one-line purpose, a usage hint, a format note, and a short Args list. Every sentence carries value with no filler, and the purpose is front-loaded.

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?

For a simple read tool with an output schema present, the description covers the essential purpose, usage guidance, output format, and parameter semantics. It omits error handling and pagination beyond max_blocks, but given the low complexity and the presence of an output schema, it is sufficiently complete.

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

Parameters5/5

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

Schema description coverage is 0%, so the description fully compensates. It explains note_id as 'ノートID' and max_blocks as '返す発言ブロックの上限。省略すると全件' (upper limit of utterance blocks to return; all if omitted), adding meaning beyond the bare schema types.

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?

The description clearly states the verb and resource: 'ノートの文字起こし全文を取得する' (get the full transcript of a note). It also differentiates from the sibling get_note_summary by explicitly naming it as the alternative for summaries, making the tool's scope unambiguous.

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

Usage Guidelines5/5

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

The description gives explicit guidance: '要約で足りる場合は get_note_summary を使うこと' (use get_note_summary if a summary is sufficient), and warns that a 1-hour meeting produces tens of KB, implying this tool is for detailed full-text retrieval. This directly informs when to choose this tool over the sibling.

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

list_notesA

AiNote のノート一覧を新しい順に取得する。要約も文字起こしも含まない。

タイトル・作成日時・音声の長さのみを返す。内容を読むには、
ここで得た noteId を get_note_summary に渡す。

Args:
    count: 取得件数。既定 20。
    cursor: 前回の応答の nextCursor。次ページを取得する場合に指定する。
ParametersJSON Schema
NameRequiredDescriptionDefault
countNo
cursorNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It reveals ordering (newest first), scope (no summaries or transcripts), the exact fields returned (title, created date, audio length), and pagination semantics. It does not mention auth or error behavior, but for a read-only list operation this is sufficient.

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 description is front-loaded with the core purpose, followed by exclusions and return fields, then a useful pointer to get_note_summary, and a concise Args section. Every sentence contributes meaningful information with no repetition.

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?

Given the presence of an output schema and only two optional parameters, the description covers ordering, pagination, returned fields, and the next-step workflow. A slight gap is the absence of any guidance about when search_notes is preferable, but that is not strictly required to invoke list_notes correctly.

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

Parameters5/5

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

The input schema provides only types and defaults with 0% description coverage. The description fully compensates: 'count' is explained as the number of items to retrieve with a default of 20, and 'cursor' is explained as the previous response's nextCursor for pagination.

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?

The description clearly states the verb and resource: 'AiNote のノート一覧を新しい順に取得する' (get a list of AiNote notes in newest order). It explicitly excludes summaries and transcripts, which distinguishes it from get_note_summary and get_note_transcript.

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?

It explains pagination by instructing the agent to pass the previous nextCursor to obtain the next page, and it routes content reading to get_note_summary. However, it does not explicitly contrast with search_notes for keyword-based retrieval, though the list vs. search distinction is reasonably inferable.

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

search_notesA

AiNote のノートをキーワードで検索する。要約も文字起こしも含まない。

検索 API の呼び出し上限は 60 回/分と他より厳しい (ツール側で 1 秒間隔に制限する)。
同じ意図でキーワードを言い換えて繰り返し検索しないこと。
件数が足りない場合は cursor でページを進める。

Args:
    query: 検索キーワード (必須)。
    count: 取得件数。既定 20。
    cursor: 前回の応答の nextCursor。
ParametersJSON Schema
NameRequiredDescriptionDefault
countNo
queryYes
cursorNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses meaningful behavioral constraints: the stricter API quota, the tool-side 1-second throttle, and pagination via nextCursor. It does not discuss side effects/auth, but a keyword search is read-only and the output schema covers return shape.

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 description is compact and front-loaded: one sentence for purpose, then behavioral warnings, then a short Args list. Every sentence earns its place and the structured layout makes it easy to scan.

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?

For a simple three-parameter search tool with an output schema present, the description covers query semantics, pagination, default count, and rate-limit behavior. It could be more explicit about what fields are searched or how to route to siblings, but nothing essential for a correct first call is missing.

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 schema has no property descriptions (0% coverage), so the Args section in the description compensates. It defines query as required, count as result count with default 20, and cursor as the previous response's nextCursor. This adds the key cursor semantics that the schema does not convey.

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?

The description opens with a specific verb and resource: 'AiNote のノートをキーワードで検索する' (search AiNote notes by keyword). It also explicitly states that summaries and transcripts are not included, which helps distinguish it from the sibling tools get_note_summary and get_note_transcript. The purpose is unambiguous.

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?

It gives concrete invocation guidance: respect the 60-calls/minute limit (throttled to 1-second intervals), don't re-run searches with paraphrased keywords, and page with cursor when results are insufficient. It does not name sibling alternatives explicitly, but the 'does not include summaries/transcripts' statement and sibling names imply when those tools would be needed.

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. 4 tool updatesv0.1.0
    • First observedget_note_summary
    • First observedget_note_transcript
    • First observedlist_notes
    • First observedsearch_notes
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

A4.7/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct retrieval mode: browsing recent notes, keyword search, AI summary, and full transcript. The descriptions explicitly cross-reference when to use which, so an agent can select unambiguously.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: list_notes, search_notes, get_note_summary, get_note_transcript. Verbs clearly indicate the operation type and nouns indicate the resource.

Tool Count5/5

Four tools are well-scoped for an unofficial read-only AiNote client. Each tool covers a distinct need without redundancy or bloat.

Completeness5/5

For a read-only note retrieval server, the surface covers browsing, searching, summarized content, and full transcript retrieval. Pagination is provided where needed, and the empty-summary case is handled by directing to the transcript, so there are no dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Snackbar MCP Server

    johnawadlow
    A
    license
    Not graded
    quality
    B
    maintenance
    A personal note store exposed as an MCP server. Enables any MCP-speaking assistant to create, search, list, and categorize notes, with per-client bearer tokens for author attribution.
    344 npm
    MIT

  • upnote-mcp

    bellx2
    A
    license
    Not graded
    quality
    A
    maintenance
    A read-only MCP server that enables searching, retrieving, and managing local UpNote notes, notebooks, and tags via SQLite and UpNote's official URL scheme.
    21 npm
    MIT