Skip to main content
Glama
SaraHan774

Obsidian Dictionary MCP Server

by SaraHan774
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Local

Obsidian Dictionary MCP Server

Obsidian vault 안에서 기술 용어 사전을 관리하기 위한 MCP 서버입니다.

설치 및 설정

1. 빌드

cd obsidian-dictionary-mcp
npm install
npm run build

2. Claude Desktop 설정

~/Library/Application Support/Claude/claude_desktop_config.json 파일을 열고 다음을 추가하세요:

{
  "mcpServers": {
    "dict": {
      "command": "node",
      "args": [
        "/path/to/obsidian-dictionary-mcp/dist/index.js",
        "--glossary-path",
        "/path/to/your/ObsidianVault/Glossary/개발용어사전.md"
      ]
    }
  }
}

3. Claude Code (CLI) 설정

Claude Code CLI에서 사용하려면 두 가지 방법 중 하나를 선택하세요:

방법 A: 프로젝트별 설정 (권장)

프로젝트 루트에 .mcp.json 파일을 생성:

{
  "mcpServers": {
    "dict": {
      "command": "node",
      "args": [
        "/path/to/obsidian-dictionary-mcp/dist/index.js",
        "--glossary-path",
        "/path/to/your/ObsidianVault/Glossary/개발용어사전.md"
      ]
    }
  }
}

방법 B: 전역 설정

~/.claude/settings.json 파일에 추가:

{
  "mcpServers": {
    "dict": {
      "command": "node",
      "args": [
        "/path/to/obsidian-dictionary-mcp/dist/index.js",
        "--glossary-path",
        "/path/to/your/ObsidianVault/Glossary/개발용어사전.md"
      ]
    }
  }
}

중요: 설정 파일을 생성하거나 수정한 후에는 Claude Code를 재시작해야 변경 사항이 적용됩니다. MCP 서버는 Claude Code가 시작될 때 설정을 읽어서 실행되기 때문입니다.

--glossary-path 옵션

--glossary-path 옵션으로 기본 용어집 경로를 설정하면:

  • 도구 호출 시 file_path 파라미터를 생략할 수 있습니다

  • 설정하지 않으면 매번 file_path를 명시해야 합니다

Related MCP server: Obsidian Tools MCP Server

사용 가능한 도구

append_entry

새 용어를 사전에 추가합니다.

파라미터:

  • file_path (선택): 사전 파일 경로 (기본 경로 설정 시 생략 가능)

  • term: 추가할 용어

  • dev_explanation: 개발자용 설명 (한국어, 1-2문장)

  • simple_explanation: 비개발자용 설명 (한국어, 1문장)

  • example: 예시 (한국어, 1줄)

search_entry

용어가 이미 존재하는지 확인합니다.

파라미터:

  • file_path (선택): 사전 파일 경로 (기본 경로 설정 시 생략 가능)

  • term: 검색할 용어

get_entry

특정 용어의 내용만 가져옵니다 (전체 파일 X).

파라미터:

  • file_path (선택): 사전 파일 경로 (기본 경로 설정 시 생략 가능)

  • term: 가져올 용어

list_terms

사전에 있는 모든 용어 목록을 반환합니다 (용어명만, 내용 X).

파라미터:

  • file_path (선택): 사전 파일 경로 (기본 경로 설정 시 생략 가능)

사전 엔트리 형식

### {term}
- 개발자용 설명: {개발자 관점의 설명}
- 비개발자용 설명: {쉬운 설명}
- 예시: {짧은 예시}

Obsidian Vault 경로

사전 파일 경로 예시:

/path/to/your/ObsidianVault/Glossary/개발용어사전.md

Available Tools

4 tools
append_entryA

Append a new glossary entry to the dictionary file. Use this to add new technical terms to the Obsidian glossary.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathNoPath to the glossary markdown file (e.g., /path/to/vault/Glossary/개발용어사전.md)
termYesThe technical term to add
dev_explanationYesDeveloper-focused explanation in Korean (1-2 sentences)
simple_explanationYesSimple explanation for non-developers in Korean (1 sentence)
exampleYesOne short example in Korean

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must fully convey behavioral traits. It does not mention side effects (e.g., file modification), error handling, or constraints (e.g., file existence). This leaves significant behavioral gaps.

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 two sentences with no superfluous words. It front-loads the action and resource, making it efficient and easy to parse.

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?

The description is minimal for a tool with no output schema. It does not explain the result (e.g., success confirmation), entry format in the file, or how duplicates are handled. While sufficient for simple cases, it lacks completeness for robust usage.

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 schema already describes all parameters. The description adds no additional semantic value beyond stating the overall purpose, meeting the baseline for high coverage.

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 uses a specific verb ('append') and resource ('glossary entry') and identifies the context ('Obsidian glossary'). It clearly distinguishes from siblings like get_entry, list_terms, and search_entry, which are read-only operations.

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 states to 'use this to add new technical terms,' which gives clear context but does not provide when-not-to-use instructions or explicitly mention alternatives. Usage is implied but not exhaustive.

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

get_entryA

Retrieve a specific entry from the glossary by term name. Returns only that entry, not the whole file.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathNoPath to the glossary markdown file
termYesThe term to retrieve

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states that the tool returns only the entry (not the whole file), which hints at read-only behavior, but it does not disclose potential errors (e.g., term not found), permission requirements, or side effects. This is insufficient for a tool with no annotation support.

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 two sentences, front-loading the purpose. Every word adds value with no redundancy or filler. It is appropriately sized for the tool's simplicity.

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 retrieval tool with 2 parameters and no output schema, the description covers the core purpose and return scope. It could improve by mentioning error handling or the role of the optional file_path, but overall it is mostly complete.

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%, so the input schema already documents both parameters. The description adds context about the return behavior but does not enhance parameter meaning beyond what the schema provides. 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 action ('Retrieve'), the resource ('specific entry from the glossary'), and the method ('by term name'). It distinguishes from siblings by emphasizing it returns only one entry, not the whole file, differentiating it from list_terms and search_entry.

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 implies usage when you need a specific entry by term name, but it does not provide explicit guidance on when to use this tool versus its siblings (append_entry, list_terms, search_entry). No when-not or alternative conditions are stated.

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

list_termsA

List all terms currently in the glossary (returns only term names, not full content).

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathNoPath to the glossary markdown file

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description is the sole source. It states the action and output but does not disclose other behavioral traits such as side effects, authentication needs, or rate limits. The description is accurate but minimal.

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 concise sentence that front-loads the core purpose and immediately specifies the output limitation. No unnecessary words.

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 simple tool with one optional parameter and no output schema, the description adequately covers what the tool does and its output. The siblings provide context for differentiation.

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 only parameter 'file_path' is already described in the input schema ('Path to the glossary markdown file'). The tool description adds no extra meaning beyond the schema, so baseline score of 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 'List all terms currently in the glossary' and specifies the output scope ('returns only term names, not full content'), which distinguishes it from siblings like get_entry that likely return full content.

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 implies when to use the tool (to get a list of term names) but does not explicitly state when not to use it or mention alternatives like get_entry for full content or search_entry for searching.

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

search_entryA

Check if a term already exists in the glossary. Returns true/false and the entry content if found.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathNoPath to the glossary markdown file
termYesThe term to search for

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided, and description lacks specificity on behavior when term not found, case sensitivity, or error handling. Does not disclose exact return format 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?

Single sentence, clear and efficient. Could be slightly more structured but not overly 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 no output schema and only one required param, description does not address behavior when optional file_path is omitted. Lacks completeness about return details.

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 covers 100% of parameters with descriptions. Description adds no additional semantic value beyond schema.

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?

Clearly states it checks term existence in glossary and returns true/false with content. Distinguishes from siblings like append_entry, get_entry, list_terms.

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?

Implicitly tells when to use (check existence before adding), but no explicit alternatives or when not to use. Could provide more context about selection among siblings.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • First observedappend_entry
    • First observedget_entry
    • First observedlist_terms
    • First observedsearch_entry
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: adding, retrieving, listing, and searching entries. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (append_entry, get_entry, list_terms, search_entry), making them predictable and easy to understand.

Tool Count4/5

With 4 tools, the set is appropriately scoped for a dictionary server. It covers essential operations (add, read, list, search) though it misses update and delete, which would be natural additions.

Completeness3/5

The tool surface covers adding, retrieving, listing, and checking existence, but notably lacks update and delete operations, which are common in dictionary management. This may be intentional but leaves gaps for full lifecycle management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Obsidian MCP

    Abrak98
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to manage Obsidian vaults through full CRUD operations, wikilink management, and section-level manipulation. It supports frontmatter editing, tag-based searching, and automated link updates to maintain vault integrity.
    MIT

  • Knowledge Assistant MCP Server

    r2d2helm
    F
    license
    A
    quality
    C
    maintenance
    Enables Claude Code to interact with Obsidian vaults by providing tools for multi-term searching, reading notes, and exploring tag-based relationships. It allows users to query, analyze, and manage their personal knowledge base directly through natural language.
    9
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SaraHan774/obsidian-dictionary-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server