Which integrations are available for this server?

Protects and preserves Markdown-specific formatting, including code blocks, WikiLinks, and standard links, during the automated translation process. Provides comprehensive tools for interacting with Obsidian vaults, including note CRUD operations, URL parsing, tag-based searching, and content management. Handles YAML frontmatter within notes, ensuring existing metadata is preserved and new translation-related tracking information is added automatically.

How do I use Obsidian Translation MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Obsidian Translation MCP Server Translate obsidian://open?vault=MyVault&file=Project.md into Japanese" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Obsidian Translation MCP Server

by nojiritakeshi

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Obsidian Translation MCP Server

Claude経由でObsidianのノートを直接翻訳・更新できるMCP (Model Context Protocol) Serverです。

主要機能

🌐 Obsidian URL解析: obsidian:// URLから直接ノートを翻訳
🔄 自動翻訳: Claude APIを使用した高品質な翻訳
💾 自動バックアップ: 翻訳前の状態を自動で保存
📝 ノート操作: 基本的なCRUD操作（作成・読み取り・更新・検索）
🔍 高度な検索: コンテンツ、タグ、関連ノートの検索
🛡️ セキュリティ: Vault制限、パス検証、エラーハンドリング

Related MCP server: obsidian-mcp-server

インストール

# リポジトリをクローン
git clone <repository-url>
cd obsidian-mcp-server

# 依存関係をインストール
npm install

# プロジェクトをビルド
npm run build

設定

.envファイルを作成：

cp .env.example .env

環境変数を設定：

# Obsidian Vaultのパス
OBSIDIAN_VAULT_PATH=/path/to/your/vault

# Anthropic APIキー
ANTHROPIC_API_KEY=sk-ant-...

# バックアップ保持期間（日数）
BACKUP_RETENTION_DAYS=30

# 環境設定
NODE_ENV=production

Claude Desktop設定ファイルを更新：

{
  "mcpServers": {
    "obsidian-translator": {
      "command": "node",
      "args": ["./dist/index.js"],
      "cwd": "/path/to/obsidian-mcp-server",
      "env": {
        "OBSIDIAN_VAULT_PATH": "/path/to/your/vault",
        "ANTHROPIC_API_KEY": "sk-ant-...",
        "NODE_ENV": "production"
      }
    }
  }
}

使用方法

基本的な翻訳

obsidian://open?vault=MyVault&file=Notes/English%20Article.md を日本語訳して

利用可能なツール

translate_obsidian_note: ノートを翻訳
create_obsidian_note: 新しいノートを作成
read_obsidian_note: ノートを読み取り
update_obsidian_note: ノートを更新
search_obsidian_notes: コンテンツで検索
search_obsidian_notes_by_tags: タグで検索

翻訳機能の詳細

保護される要素

✅ YAMLフロントマター
✅ コードブロック (```)
✅ WikiLink ([[リンク]])
✅ Markdownリンク ([テキスト](URL))

翻訳モード

replace: 元のファイルを置き換え（デフォルト）
append: 翻訳を追記
parallel: 並列版を作成（例：note.ja.md）

自動追加メタデータ

translated:
  date: 2024-01-01T00:00:00.000Z
  target_language: 日本語
  model: claude-3-haiku-20240307

開発

開発モード

npm run dev

テスト

npm test

ビルド

npm run build

トラブルシューティング

よくある問題

"Vault mismatch"エラー
- 環境変数のVaultパスとURL内のVault名が一致しているか確認
"File not found"エラー
- ファイルパスが正しいか確認
- ファイルが実際に存在するか確認
"Permission denied"エラー
- Vaultディレクトリの読み書き権限を確認

ログ確認

# サーバーログを確認
tail -f ~/.claude/logs/mcp-server.log

セキュリティ

🔒 Vault制限: 指定されたVault以外へのアクセスを禁止
🛡️ パス検証: ディレクトリトラバーサル攻撃を防止
💾 必須バックアップ: 破壊的操作前に自動バックアップ
🔐 APIキー保護: 環境変数で管理、ログ出力禁止

ライセンス

MIT License

作者

[Your Name]

貢献

バグ報告や機能要請は、GitHubのIssuesまでお願いします。

🔗 関連リンク

Available Tools

6 tools

create_obsidian_noteC

Create a new Obsidian note with optional frontmatter and tags

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path for the new note (relative to vault root, e.g., "folder/note.md")
`title`	Yes	Title of the note
`content`	Yes	Content of the note
`tags`	No	Tags to add to the note
`template`	No	Template to use for the note (optional)

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must bear the full burden of transparency. It does not disclose key behaviors: what happens if the path exists, how frontmatter is handled (frontmatter is mentioned but not a parameter), whether the vault must exist, or any rate limits. This is a significant gap.

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

Conciseness3/5

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

The description is a single sentence, which is concise, but it omits critical details for a 5-parameter tool with no annotations. It is front-loaded with the main action but sacrifices completeness.

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

Completeness2/5

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

Given the complexity (5 parameters, no output schema, no annotations), the description is insufficient. It does not explain the creation process, prerequisites, or expected behavior when a note already exists. The mention of frontmatter misaligns with the schema.

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

Parameters2/5

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

The schema covers all parameters with descriptions (100% coverage), so baseline is 3. However, the description mentions 'frontmatter' which is not a parameter in the schema, causing confusion. It adds no meaningful semantics beyond the param descriptions.

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?

The description clearly identifies the tool as creating an Obsidian note, with optional frontmatter and tags. The verb 'Create' and resource 'a new Obsidian note' are specific, but it does not differentiate from sibling tools like update_obsidian_note.

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?

No guidance is given on when to use this tool versus alternatives. For example, it does not state that this tool is for new notes while update_obsidian_note is for modifying existing ones. The description only implies usage via the action verb.

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

read_obsidian_noteB

Read content of an existing Obsidian note

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the note (relative to vault root)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Description only says 'read' but does not disclose whether it returns raw markdown, file metadata, or any limitations (e.g., file size, encoding). The behavioral traits are underspecified.

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?

Single sentence with no redundancy. For a simple read tool, this is appropriately concise. However, it could be slightly expanded to include return format without losing conciseness.

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

Completeness3/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 should clarify what the tool returns (e.g., 'Returns the full content as a string'). The current description is minimal but insufficient for a complete understanding of the tool's behavior.

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 coverage is 100% for the only parameter 'path'. The description adds no semantic information beyond what the schema already provides (path relative to vault root). Baseline 3 is appropriate.

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 tool reads content of an existing Obsidian note, which is a specific verb+resource combination. It distinguishes itself from sibling tools like create, search, update, translate, and search by tags.

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?

No guidance on when to use this tool versus alternatives. For example, it does not clarify that this tool is for retrieving content and not for searching or modifying notes. The agent must infer usage from the name.

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

search_obsidian_notesC

Search for notes in Obsidian vault by content or title

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query (searches in both title and content)
`directory`	No	Directory to search in (relative to vault root, optional)
`maxResults`	No	Maximum number of results to return
`includeContent`	No	Whether to include content excerpts in results

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavior. It only states 'Search for notes' without clarifying read-only nature, performance, or what happens with no results. The behavioral profile is insufficiently described.

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 a single concise sentence with no wasted words. However, it could be slightly more informative without adding length, e.g., specifying 'full-text search' or 'includes content excerpts'.

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

Completeness2/5

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

Given no output schema, the description should hint at return format or scope. It does not mention that results include content excerpts (default true) or that maxResults limits output. The agent lacks context on what to expect from the response.

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?

The input schema details all four parameters with descriptions (100% coverage). The tool description adds no new information beyond what the schema already provides, so it meets the baseline but does not enhance understanding.

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?

The description clearly states it searches notes by content or title. However, it does not explicitly differentiate from the sibling 'search_obsidian_notes_by_tags', which is a distinct search method. The purpose is clear but could be more specific.

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?

No guidance on when to use this tool versus alternatives like 'search_obsidian_notes_by_tags'. The description does not mention when to search by content/title vs. tags, leaving the agent to infer without explicit instruction.

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

search_obsidian_notes_by_tagsC

Search for notes by tags

ParametersJSON Schema

Name	Required	Description	Default
`tags`	Yes	Tags to search for
`matchMode`	No	Whether to match any tag or all tags	any
`maxResults`	No	Maximum number of results to return

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only says 'Search for notes by tags' but doesn't explain return format, performance, or side effects.

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 concise (one sentence) with no fluff. However, it could be improved with more useful detail while remaining brief.

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

Completeness3/5

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

Given no output schema and simple parameters, the description is minimally adequate but lacks info on return format or results structure.

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?

The input schema already has 100% descriptive coverage for parameters. The description adds no extra meaning beyond what the schema provides.

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?

The description clearly states the tool searches for notes by tags, which is the main purpose. However, it does not distinguish from the sibling tool 'search_obsidian_notes' which may search by other criteria.

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?

No guidance is provided on when to use this tool versus alternatives like 'search_obsidian_notes' or 'read_obsidian_note'. No when-not-to-use or prerequisites mentioned.

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

translate_obsidian_noteB

Translate an Obsidian note from obsidian:// URL and update the original file

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Obsidian URL in format: obsidian://open?vault=VaultName&file=path/to/note.md
`targetLanguage`	No	Target language for translation (default: 日本語)	日本語
`mode`	No	Translation mode: replace original, append translation, or create parallel version	replace

TDQS

B3.1/5.0

Behavior2/5

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

The description says 'update the original file,' but the schema includes modes 'append' and 'parallel' that do not solely update the original. This omission may mislead agents about the actual behavior. No disclosure of side effects, failure modes, or limitations.

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 a single sentence with no redundant information. It is concise, but could be slightly more informative without becoming verbose.

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

Completeness2/5

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

Given three parameters (including an enum) and no output schema, the description fails to explain the effects of different modes, translation behavior (e.g., handling of formatting/links), or what success looks like. The agent may not properly invoke the tool with correct mode expectations.

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 coverage is 100% with parameter descriptions, so baseline is 3. The description adds no extra meaning to the parameters (e.g., does not explain the URL format beyond the schema or elaborate on mode differences).

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 tool translates an Obsidian note from an obsidian:// URL and updates the original file. The verb 'translate' and resource 'Obsidian note' are specific, distinguishing it from sibling tools like create, read, search, or update.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., update_obsidian_note). There is no mention of when to avoid it or prerequisites like ensuring the note exists.

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

update_obsidian_noteB

Update an existing Obsidian note

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the note (relative to vault root)
`content`	Yes	New content for the note
`mode`	No	Update mode: replace, append, or prepend content	replace
`createBackup`	No	Whether to create a backup before updating

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are given, so the description must fully convey behavior. It only says 'Update an existing Obsidian note' without disclosing error handling, return value, or confirmation behavior. The schema hints at backup defaults and modes, but the description adds no extra context.

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 a single sentence with no redundant information, perfectly concise for a straightforward update tool.

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

Completeness2/5

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

With no output schema and 4 parameters, the description lacks critical details: what is returned (e.g., success status), error scenarios (e.g., note not found), and when to use each mode. It is incomplete for an agent to invoke correctly without additional knowledge.

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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter purpose or provide examples.

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 action ('Update') and the resource ('an existing Obsidian note'), distinguishing it from siblings like create or read.

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?

No explicit when-to-use or when-not-to-use guidance is provided. The description does not differentiate between modes (replace, append, prepend) or compare with create/read, leaving usage implied.

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.

6 tool updatesv1.0.0Apr 29, 2026
- First observedcreate_obsidian_note
- First observedread_obsidian_note
- First observedsearch_obsidian_notes
- First observedsearch_obsidian_notes_by_tags
- First observedtranslate_obsidian_note
- First observedupdate_obsidian_note

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored 2026-04-29 02:20 across 6 tools

Disambiguation5/5

Each tool targets a distinct action: create, read, search (by content/title), search by tags, translate, and update. No two tools have overlapping purposes; the two search tools are clearly differentiated by their search method.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., create_obsidian_note, search_obsidian_notes, translate_obsidian_note). The naming is uniform and predictable.

Tool Count5/5

With 6 tools, the server is well-scoped for managing Obsidian notes with translation capabilities. Each tool serves a distinct purpose, and the count is neither too sparse nor overwhelming.

Completeness4/5

The tool set covers core note operations (create, read, update, search) and adds translation. A delete tool is missing, but otherwise the surface is adequate for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

notesbridgeOAuth
io.github.IsaiahDupree
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
Note Taking App Automation
1
TaprootOAuth
com.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Knowledge & Memory Note Taking
2
Jade NoteOAuth
app.jadenote
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Note Taking Knowledge & Memory
2
memolOAuth
app.memol
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
Note Taking Search
2

Related MCP Servers

Obsidian MCP Server
Note Taking File Systems Version Control
townofnolan
F
license
Not graded
quality
Not graded
maintenance
Enables Claude to read, write, search, and manage Obsidian vault notes with Git-backed sync support for multi-device access and extensible AI workflows.
Updated 10 months ago (2025-11-16 01:47 UTC)
6,584
-
obsidian-mcp-server
Note Taking Search
shivamsharmxa
A
license
Not graded
quality
D
maintenance
Connects Claude.ai to your local Obsidian vault for full CRUD access, search, and daily note creation via the Model Context Protocol.
Updated 6 months ago (2026-03-19 10:55 UTC)
36
14
MIT
obsidian-mcp-server
Note Taking Knowledge & Memory
indie-geeker
A
license
Not graded
quality
D
maintenance
Enables AI to manage Obsidian notes, including creation, reading, updating, deletion, full-text search, listing with filtering, sorting, and metadata extraction via the Model Context Protocol.
Updated a year ago (2025-10-23 09:07 UTC)
18
MIT
obsidian-local-mcp
Note Taking File Systems
chs2147
F
license
A
quality
C
maintenance
Enables Claude to create, read, update, and search notes in a local Obsidian vault, with automatic YAML frontmatter and folder management.
Updated 3 months ago (2026-06-26 23:46 UTC)
7
1
-