Memex

모델 컨텍스트 프로토콜을 위한 Memex
Memex는 웹 콘텐츠를 분석하고 지식 기반에 추가할 수 있는 MCP(Model Context Protocol) 도구입니다.
이 도구는 Vannevar Bush 의 Memex 프로젝트에서 영감을 얻었습니다.
요구 사항
다음 서비스를 이용하려면 API 키가 필요합니다.
이 도구로 생성된 지식 기반은 마크다운 파일로 저장되므로 모든 마크다운 뷰어로 볼 수 있지만 Obsidian을 사용하는 것이 좋습니다.
Related MCP server: Documentation Crawler & MCP Server
설치
지엑스피1
claude_desktop_config.json 에 다음을 추가하고 플레이스홀더를 실제 경로와 API 키로 바꾸세요.
{
"mcpServers": {
"memex": {
"command": "uv",
"args": [
"--directory",
"PATH_TO_LOCAL_MEMEX_REPO",
"run",
"mcp-memex",
"--index",
"PATH_TO_MEMEX_INDEX",
"--workspace",
"PATH_TO_OBSIDIAN_VAULT"
],
"env": {
"ANTHROPIC_API_KEY": "YOUR-API-KEY",
"FIRECRAWL_API_KEY": "YOUR-API-KEY",
"VOYAGE_API_KEY": "YOUR-API-KEY"
}
}
}
}용법
먼저 클로드에게 참조할 URL 목록을 적어 질문을 던지세요.
What is the capital of France? "https://en.wikipedia.org/wiki/France"클로드가 콘텐츠 분석을 완료하면 Obsidian 보관소에서 결과를 확인할 수 있습니다. 콘텐츠에 대해 질문하시면 Memex가 지식 기반을 활용하여 답변해 드립니다.
What is the capital of France?개발
도구를 로컬로 실행하려면 다음 명령을 사용하면 됩니다.
npx @modelcontextprotocol/inspector \
uv \
--directory PATH_TO_LOCAL_MEMEX_REPO \
run \
mcp-memex \
--index PATH_TO_MEMEX_INDEX \
--workspace PATH_TO_OBSIDIAN_VAULT그런 다음 검사기를 열고 서버에 연결합니다.
Available Tools
3 toolsanalyze_web_contentA
Analyze multiple web pages and extract relevant information based on your query. This tool fetches and processes the content from provided URLs to answer your specific questions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you want to learn or understand from these web pages | |
| urls | Yes | A comma-separated list of web page URLs you want to analyze |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It states the tool fetches and processes content, indicating read behavior, but does not disclose details like error handling, rate limits, or authentication needs. The behavioral disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the purpose, and the second adds context. It is front-loaded and efficient, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers the main behavior but does not describe the return format or address edge cases like invalid URLs. It is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema (e.g., 'based on your query', 'provided URLs'), but does not elaborate on parameter constraints or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: analyze multiple web pages and extract relevant information based on a query. The verb 'analyze' and resource 'web pages' are specific, and the purpose is distinct from siblings like save_artifact and search_knowledge_base.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have URLs and a query) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_artifactB
Save an artifact to the knowledge base
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The complete content of the artifact to save |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details such as whether saving overwrites existing artifacts, any constraints on content, or side effects. No annotations are present to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is efficient but could include more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what happens after saving (e.g., storage behavior, retrieval) or how the artifact is identified. Missing context for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented. The description adds no new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Save' and the resource 'artifact to the knowledge base'. It effectively distinguishes from sibling tools 'analyze_web_content' and 'search_knowledge_base', which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_knowledge_baseB
Search through previously analyzed content in the knowledge base using natural language. This tool helps you find relevant information from your stored content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What information you're looking for in your knowledge base |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the full burden. It suggests a read operation ('search through') but does not explicitly confirm non-destructive behavior or disclose limitations like search scope or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. Front-loaded with the action and resource, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet description does not describe return values (e.g., snippets, relevance scores). Lacks details on search behavior, pagination, or result scope, making it incomplete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'What information you're looking for in your knowledge base'. Description adds 'using natural language', which provides minor extra context beyond the schema, but not significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search through previously analyzed content in the knowledge base using natural language', with a specific verb and resource. It distinguishes from sibling tools like 'analyze_web_content' and 'save_artifact' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding stored content but does not explicitly state when to use it over siblings or provide exclusions. No alternatives or conditions mentioned.
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.
3 tool updates
v0.1.0- First observed
analyze_web_content - First observed
save_artifact - First observed
search_knowledge_base
TDQS
Scored across 3 tools
Each tool targets a distinct action: analyze web content, save to knowledge base, and search the knowledge base. There is no overlap in their purposes.
All tool names follow a consistent verb_noun pattern with snake_case (analyze_web_content, save_artifact, search_knowledge_base), making them predictable and easy to understand.
With only 3 tools, the server feels slightly under-scoped for a knowledge base system, but it may be intentionally focused on core web analysis and storage/search functionality.
The tool set covers creating artifacts and searching, but lacks update, delete, or listing capabilities, which are notable gaps for managing a knowledge base over time.
Maintenance
Related MCP Connectors
Personal knowledge MCP: capture bookmarks, notes & todos by chat; archive pages; search memory.
Convert files, URLs, and documents to clean, AI-ready Markdown via MCP.
AI research library. Save, organise and reuse notes and webpages as clean markdown context.
Publish and share access-controlled Markdown documents from any MCP-enabled AI tool.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that allows LLMs to interact with web content through standardized tools, currently supporting web scraping functionality.1MIT
- AlicenseNot gradedqualityDmaintenanceToolset that crawls websites, generates Markdown documentation, and makes that documentation searchable via a Model Context Protocol (MCP) server for integration with tools like Cursor.42MIT
- AlicenseNot gradedqualityDmaintenanceA self-hosted MCP server that reads web pages and converts them to Markdown, with built-in web search and anti-crawl fallback using Playwright.1MIT
- AlicenseNot gradedqualityCmaintenanceA web scraping CLI tool that converts web pages to markdown and also runs as an MCP server for agent integration.10 npm11MIT