Skip to main content
Glama
enesjakozh
anpigon

Obsidian Omnisearch MCP Server

by anpigon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

MCP 서버 Obsidian Omnisearch

대장간 배지 REST API 인터페이스를 통해 Obsidian 볼트 검색 기능을 제공하는 FastMCP 기반 서버입니다.

개요

이 프로젝트는 Obsidian 볼트 노트를 프로그래밍 방식으로 검색할 수 있는 검색 서비스를 구현합니다. FastMCP를 사용하여 검색 기능을 다른 서비스와 통합 가능한 도구로 제공합니다.

Related MCP server: Obsidian MCP Server

특징

  • 흑요석 보관소 노트 검색

  • REST API 통합

  • 일치하는 노트에 대한 절대 경로를 반환합니다.

  • FastMCP 도구와의 쉬운 통합

필수 조건

  • 파이썬 3.x

  • Omnisearch 플러그인이 설치되고 실행 중인 Obsidian

  • FastMCP 라이브러리

  • 활성 흑요석 금고

설치

Smithery를 통해 설치

Smithery를 통해 Claude Desktop용 MCP Server Obsidian Omnisearch를 자동으로 설치하려면:

지엑스피1

수동 설치

  1. 저장소를 복제합니다.

git clone https://github.com/anpigon/mcp-server-obsidian-omnisearch.git
cd mcp-server-obsidian-omnisearch

  1. 종속성 설치:

uv install

구성

이제 서버를 실행할 때 Obsidian 볼트 경로가 명령줄 인수로 제공됩니다.

python server.py /path/to/your/obsidian/vault

용법

Obsidian Omnisearch API

Obsidian Omnisearch 커뮤니티 플러그인을 실행해야 합니다: https://publish.obsidian.md/omnisearch/Inject+Omnisearch+results+into+your+search+engine

클로드 데스크탑

MacOS의 경우: ~/Library/Application\ Support/Claude/claude_desktop_config.json

Windows의 경우: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "obsidian-omnisearch": {
      "command": "uv",
      "args": [
        "--directory",
        "<dir_to>/mcp-server-obsidian-omnisearch",
        "run",
        "mcp-server-obsidian-omnisearch",
        "/path/to/your/obsidian/vault"
      ]
    }
  }
}
{
  "mcpServers": {
    "obsidian-omnisearch": {
      "command": "uvx",
      "args": [
        "mcp-server-obsidian-omnisearch",
        "/path/to/your/obsidian/vault"
      ]
    }
  }
}

API 참조

검색 노트

  • 함수: obsidian_notes_search(query: str)

  • 설명: Obsidian 노트를 검색하고 일치하는 노트의 절대 경로를 반환합니다.

  • 매개변수:

    • query : 검색 쿼리 문자열

  • 반환: 일치하는 노트에 대한 절대 경로 목록

개발

건축 및 출판

배포를 위해 패키지를 준비하려면:

  1. 종속성 동기화 및 잠금 파일 업데이트:

uv sync

  1. 패키지 배포 빌드:

uv build

이렇게 하면 dist/ 디렉토리에 소스와 휠 배포판이 생성됩니다.

  1. PyPI에 게시:

uv publish

참고: 환경 변수나 명령 플래그를 통해 PyPI 자격 증명을 설정해야 합니다.

  • 토큰: --token 또는 UV_PUBLISH_TOKEN

  • 또는 사용자 이름/비밀번호: --username / UV_PUBLISH_USERNAME 및 --password / UV_PUBLISH_PASSWORD

디버깅

MCP 서버는 stdio를 통해 실행되므로 디버깅이 어려울 수 있습니다. 최상의 디버깅 환경을 위해서는 MCP Inspector 사용을 강력히 권장합니다.

다음 명령을 사용하여 npm 통해 MCP Inspector를 시작할 수 있습니다.

npx @modelcontextprotocol/inspector uv --directory /path/to/mcp-server-obsidian-omnisearch run mcp-server-obsidian-omnisearch

Inspector를 실행하면 브라우저에서 접근하여 디버깅을 시작할 수 있는 URL이 표시됩니다.

다음 명령을 사용하여 서버 로그를 볼 수도 있습니다.

tail -n 20 -f ~/Library/Logs/Claude/mcp-server-mcp-server-obsidian-omnisearch.log

종속성

  • 패스트MCP

  • 요청

  • URL 라이브러리

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

기여하다

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

Available Tools

2 tools
read_noteC

Read and return the contents of an Obsidian note file.

ParametersJSON Schema
NameRequiredDescriptionDefault
filepathYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions reading and returning contents, which implies a read-only operation, but doesn't specify error handling (e.g., what happens if the file doesn't exist), permissions required, or format of returned data. This leaves significant gaps for a tool with no annotation coverage.

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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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 lack of annotations and output schema, the description is insufficient for a tool that reads files. It doesn't cover error cases, return format, or parameter details, leaving the agent with incomplete information to use the tool effectively in a real-world context.

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 description coverage is 0%, and the description doesn't explain the 'filepath' parameter beyond what's implied by the tool name. It doesn't specify the expected format (e.g., relative vs absolute path, file extension requirements) or provide examples, failing to compensate for the lack of schema documentation.

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 action ('Read and return the contents') and resource ('an Obsidian note file'), making the tool's purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'obsidian_notes_search', which likely serves a different purpose (searching vs reading specific files).

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?

The description provides no guidance on when to use this tool versus alternatives like 'obsidian_notes_search', nor does it mention any prerequisites or contextual constraints. It merely states what the tool does without indicating appropriate usage scenarios.

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. 2 tool updatesv1.0.0
    • Changedobsidian_notes_search1 field changed
      • removedInput schema / properties / query / title
        Removed value: -"Query"
    • Changedread_note1 field changed
      • removedInput schema / properties / filepath / title
        Removed value: -"Filepath"
  2. 2 tool updates
    • First observedobsidian_notes_search
    • First observedread_note
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one searches for notes and returns paths, while the other reads the content of a specific note. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tools follow a consistent snake_case naming pattern with clear verb_noun structure (obsidian_notes_search, read_note). The naming is predictable and readable throughout.

Tool Count2/5

With only two tools, the server feels thin for its purpose of Obsidian Omnisearch. While the tools cover basic search and read operations, the scope suggests more functionality (e.g., create, update, delete notes, or advanced search features) would be expected.

Completeness2/5

The server is severely incomplete for an Obsidian search domain. It lacks any CRUD operations (create, update, delete notes) and advanced search capabilities (e.g., filtering by tags, dates). Agents will hit dead ends when trying to perform common note management tasks.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches