What can you do with this server?

This server provides a persistent, locally stored personal knowledge base that lets AI assistants instantly understand your background, skills, preferences, and style. It uses tiered visibility (public, recruiter, friend, private) to control access, stores data as portable markdown files, and runs offline via stdio. Key tools include: * who_am_i: Reveals all visible context at a given tier, enabling instant AI onboarding. * list_context: Lists available context sections by title, slug, tier, and tags. * get_context: Retrieves full content of a section by slug. * search_context: Performs keyword search across all visible sections, returning snippets. * save_context: Writes or updates a context section (e.g., after AI parses a file). * extract_file: Extracts plain text from PDF, DOCX, TXT, or MD files for AI processing.

How do I use personal-context-mcp?

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., "@personal-context-mcp call who_am_i to learn about me" 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.

personal-context-mcp

by KrystalJin1

Overview Schema Related Servers Score Discussions

Python

Local

🧠 personal-context-mcp

把「你是谁」存一次，让每个 AI 都记得你。 Store who you are once — let every AI remember you.

MCP Python Made with uv License: MIT

中文 · English

▲ 接入后对任意 AI 说「调用 who_am_i」，它一次就读到你完整的上下文

🇨🇳 中文

✨ 这是什么

换一个新 AI、新开一个聊天框，你是不是又得从头交代一遍「我是谁、我喜欢什么风格、我做过什么」？

personal-context-mcp 把这些存成 markdown，通过 MCP（Model Context Protocol） 暴露成一组工具。任何支持 MCP 的 AI（Claude Code、Claude Desktop、Cursor…）接上后，调用一次 who_am_i 就「认识你」，不用再自我介绍。

📦 数据一份，插头随时加 · ☁️ 放 GitHub 永久免费 · 🔌 本地 stdio 零托管 · 🔐 分层可见

⏱️ 30 秒看效果

同样一句「帮我改简历」，接入前后 AI 的反应完全不同：

❌ 没有它（每次都从头认识你）

你  ：帮我改简历
AI ：好的，先了解一下你——你是做什么方向的？
     常用哪些技术栈？想投什么岗位？偏好什么写作风格？
你  ：（又要把背景、技术栈、风格偏好从头敲一遍……）

✅ 有了它（一句话，AI 秒懂你是谁）

你  ：先调用 who_am_i 了解我，然后帮我改简历
AI ：〔调用 who_am_i〕
     好的，已了解你的背景（LLM 预训练 / 长文本 / 分布式）、
     偏好（中文、先定风格再动手）和写作习惯。
     基于这些，我把「书籍数据 SFT」项目改写得更突出你的贡献……

差别就在于：上下文只需存一次，之后每个新 AI、每个新对话都直接读，不用再自我介绍。

💡 核心理念

	说明
📦 数据与服务分离	你的资料是 `context/` 下的纯 markdown，放在你自己的 git 仓库里；server 只是薄薄一层，随时可换、可拔。
☁️ 永久留存、不吃算力	跟 GPU 无关。数据放 GitHub 永久免费，server 本地跑、断网可用。哪天没有任何服务器，光靠这个 git 仓库你依然拥有全部资料。
🔐 分层可见（tier）	`public ⊂ recruiter ⊂ friend ⊂ private`。同一份资料，陌生人 / 招聘方 / 朋友 / 自己看到的范围不同。

📁 目录结构

personal-context-mcp/
├── server.py             # 🔌 MCP server（stdio）
├── context/              # ★ 数据层：你的资料，改这里
│   ├── style.md          # 🎨 风格习惯
│   ├── preferences.md    # ⚙️ 偏好设置
│   ├── skills.md         # 🧰 用过的 skill
│   ├── background.md     # 📖 人生背景（可公开）
│   └── private.md        # 🔒 私密信息（gitignore，仅本地 tier=private 可见）
├── ingest/import_file.py # 📄 简历/文件 → 纯文本（供 AI 解析）
└── pyproject.toml

🚀 快速开始

# 1) 装依赖（mcp / pyyaml / pypdf / python-docx）
cd personal-context-mcp
uv sync

# 2) 本地可视化调试（打开 MCP Inspector，逐个点工具试）
uv run mcp dev server.py

# 3) 接入 Claude Code / Cursor
uv run mcp install server.py --name personal-context

或手动在 AI 的 MCP 配置里加一段（注意换成绝对路径）：

{
  "mcpServers": {
    "personal-context": {
      "command": "uv",
      "args": ["--directory", "/绝对路径/personal-context-mcp", "run", "python", "server.py"]
    }
  }
}

接入后，对 AI 说一句 「调用 who_am_i 了解我」 就行 ✅

🔄 它是怎么工作的

flowchart LR
    A["📝 context/*.md<br/>你的资料"] --> B["🔌 MCP Server<br/>server.py (stdio)"]
    B -->|"who_am_i / search…"| C["🤖 任意 AI<br/>Claude / Cursor…"]
    C -->|"save_context 写回"| A
    D["📄 简历 / 文件"] -->|"extract_file"| C

🧰 提供的工具

工具	作用
🙋 `who_am_i(viewer_tier)`	一次性返回该 tier 下全部可见内容，换新 AI 时用它「一键认识你」
📋 `list_context(viewer_tier)`	列出所有板块
📖 `get_context(slug, viewer_tier)`	读某个板块全文
🔍 `search_context(query, viewer_tier)`	关键词搜索
💾 `save_context(slug, title, body, tier, tags)`	写入/更新板块（AI 整理完经历后存回来）
📄 `extract_file(path)`	抽取 pdf/docx/txt/md 文本，供 AI 解析简历

📄 上传简历 / 文件，自动整理进知识库

不用写死解析逻辑 —— 让 AI 来做：

让 AI extract_file("我的简历.pdf") 拿到纯文本；
AI 解析、优化成结构化内容；
AI save_context(slug="background", …) 写回 context/。

命令行也能单独抽文本：uv run python ingest/import_file.py 我的简历.pdf

🧪 测试

核心逻辑（tier 权限过滤、搜索、写回、非法 slug 拦截）都有单测：

uv run pytest            # 或 .venv/bin/python -m pytest

🔐 分层可见（tier）

每个 .md 头部的 tier 字段决定谁能看到：

public   ⊂   recruiter   ⊂   friend   ⊂   private
陌生人        招聘方          朋友        只有自己

调用时传 viewer_tier，server 只返回该层级及以下的内容。私密信息（如内网路径、身份细节）建议单独放 context/private.md 并加进 .gitignore，这样它永不进入 GitHub，只在本地 tier=private 时可见。

☁️ 留存到 GitHub

cd personal-context-mcp
git add . && git commit -m "update my context"
git push

💡 context/private.md 已在 .gitignore 里；其余板块默认可公开。若想全部私有，直接用私有仓库即可。

Related MCP server: Personal Context Manager

🇬🇧 English

✨ What is this

Every time you switch to a new AI or open a fresh chat, you re-explain who you are, what style you like, what you've built. 😮‍💨

personal-context-mcp stores all of that as markdown and exposes it through the Model Context Protocol (MCP). Any MCP-capable AI (Claude Code, Claude Desktop, Cursor…) plugs in, calls who_am_i once, and instantly knows you — no more re-onboarding.

📦 One data source, plug in anytime · ☁️ Free forever on GitHub · 🔌 Local stdio, zero hosting · 🔐 Tiered visibility

⏱️ See it in 30 seconds

Same prompt — "help me polish my resume" — a world of difference before vs. after:

❌ Without it (re-onboarding every time)

You : Help me polish my resume.
AI  : Sure — first, what field are you in? Which tech stack do you
      use? What roles are you targeting? Any writing-style preferences?
You : (typing out my background, stack and style preferences… again.)

✅ With it (one line, and the AI just knows you)

You : Call who_am_i to learn about me, then polish my resume.
AI  : 〔calls who_am_i〕
      Got it — I know your background (LLM pretraining / long-context /
      distributed), your preferences and writing style. Based on that,
      I've rewritten the "book-data SFT" project to highlight your impact…

The point: store your context once, and every new AI and every new chat reads it directly — no more self-introductions.

💡 Core ideas


📦 Data ≠ server	Your data is plain markdown under `context/`, living in your own git repo. The server is a thin, swappable layer.
☁️ Permanent, compute-free	No GPU involved. Data lives on GitHub for free; the server runs locally and works offline. Even with no server anywhere, the git repo alone keeps all your data.
🔐 Tiered visibility	`public ⊂ recruiter ⊂ friend ⊂ private`. Strangers / recruiters / friends / you each see a different slice of the same data.

📁 Layout

personal-context-mcp/
├── server.py             # 🔌 MCP server (stdio)
├── context/              # ★ data layer — edit these
│   ├── style.md          # 🎨 style & habits
│   ├── preferences.md    # ⚙️ preferences
│   ├── skills.md         # 🧰 skills used
│   ├── background.md     # 📖 background (public-safe)
│   └── private.md        # 🔒 private (gitignored, tier=private only)
├── ingest/import_file.py # 📄 resume/file → plain text (for the AI to parse)
└── pyproject.toml

🚀 Quick start

# 1) install deps
cd personal-context-mcp
uv sync

# 2) local visual debugging (MCP Inspector)
uv run mcp dev server.py

# 3) install into Claude Code / Cursor
uv run mcp install server.py --name personal-context

Or add this to your AI's MCP config (use an absolute path):

{
  "mcpServers": {
    "personal-context": {
      "command": "uv",
      "args": ["--directory", "/abs/path/personal-context-mcp", "run", "python", "server.py"]
    }
  }
}

Then just tell the AI: "Call who_am_i to learn about me." ✅

🧰 Tools

Tool	Purpose
🙋 `who_am_i(viewer_tier)`	Return everything visible at that tier in one shot — "know me instantly"
📋 `list_context(viewer_tier)`	List all sections
📖 `get_context(slug, viewer_tier)`	Read one section
🔍 `search_context(query, viewer_tier)`	Keyword search
💾 `save_context(slug, title, body, tier, tags)`	Write/update a section
📄 `extract_file(path)`	Extract text from pdf/docx/txt/md for the AI to parse

📄 Import a resume, let the AI organize it

No hard-coded parsing — let the AI do it:

AI calls extract_file("resume.pdf") to get plain text;
AI parses and structures it;
AI calls save_context(slug="background", …) to write it back.

CLI also works: uv run python ingest/import_file.py resume.pdf

🧪 Tests

The core logic (tier filtering, search, write-back, illegal-slug rejection) is covered by unit tests:

uv run pytest            # or: .venv/bin/python -m pytest

🔐 Tiered visibility

The tier field in each .md front-matter controls who sees it. The server returns only content at or below the requested viewer_tier. Keep private data (internal paths, identity details) in context/private.md and gitignore it — it never reaches GitHub and shows only at local tier=private.

☁️ Persist to GitHub

git add . && git commit -m "update my context"
git push

Made with 🧠 by KrystalJin1 · MIT License

Available Tools

6 tools

extract_fileA

抽取 pdf / docx / txt / md 文件的纯文本，供 AI 解析、优化后再 save_context。（这是「上传简历→解析」的第一步：只取文本，优化交给 AI 本身。）

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses file types and the extraction-only behavior, but lacks details on error handling, size limits, or output format. The presence of an output schema reduces the need for return value details, but the description does not cover behavioral traits.

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 with two sentences, front-loading the main purpose. It is structured logically but could be slightly more organized.

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?

For a simple tool with one parameter and an output schema, the description covers core functionality and context. However, it lacks parameter details and behavioral aspects, leaving gaps for the agent.

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

Parameters1/5

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

The input schema has 0% coverage with no parameter descriptions, and the description does not elaborate on the path parameter (e.g., format, constraints). Thus, it adds no value beyond the 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?

The description clearly states the tool extracts plain text from pdf/docx/txt/md files, which is a specific verb+resource. It distinguishes from sibling tools like save_context by explaining it is a preliminary step.

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?

The description provides context on when to use the tool as the first step before save_context, and clarifies that optimization is left to AI. However, it does not explicitly exclude alternative scenarios.

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

get_contextC

读取某个板块的完整内容。slug 见 list_context。

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes
`viewer_tier`	No		private

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided; description only says '读取完整内容' (read complete content) but does not disclose permissions, auth needs, rate limits, or mutation effects.

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?

Extremely concise (one sentence) and front-loaded, but lacks structure and omits necessary details.

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?

Despite having output schema, description barely covers two parameters and lacks behavior explanation; insufficient for a tool with 1 required param.

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

Parameters1/5

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

Schema description coverage is 0%; description only mentions 'slug' indirectly but provides no meaning for 'viewer_tier'. Fails to add value beyond parameter names.

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?

Description clearly states the verb '读取' (read), resource '板块完整内容' (section content), and references sibling tool for slug, distinguishing it from list_context and search_context.

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 explicit guidance on when to use get_context over siblings. Only implies slug from list_context but lacks conditions or alternatives.

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

list_contextA

列出所有可见的个人上下文板块（标题、slug、tier、标签）。 viewer_tier: public/recruiter/friend/private，决定能看到哪些内容。

ParametersJSON Schema

Name	Required	Description	Default
`viewer_tier`	No		private

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/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 full weight. It discloses that the tool lists 'visible' boards filtered by viewer_tier, which is a key behavioral trait. It does not explicitly state that the operation is read-only, but '列表' (list) implies no side effects. The presence of an output schema compensates for not detailing the return format.

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 composed of two concise sentences. The first sentence states the core purpose and output fields. The second sentence explains the parameter. Every word adds value, and the key information 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?

Given the presence of an output schema, the description adequately covers the tool's purpose and parameter. It is complete enough for a listing tool with a single optional parameter. It does not mention pagination or ordering, but these are not critical for basic usage; the output schema likely handles structure.

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 description adds significant meaning to the viewer_tier parameter beyond the schema. It lists the allowed values (public/recruiter/friend/private) and explains that it determines visibility. The schema only defines it as a string with a default, so the description is essential for correct usage.

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 specifies the verb '列表' (list) and the resource '个人上下文板块' (personal context boards), clearly indicating the tool's function. It also explicitly mentions the fields returned (title, slug, tier, tags). This distinguishes it from siblings like get_context (likely single item retrieval) and search_context (searching).

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 explains the viewer_tier parameter and its effect on visibility, which gives usage context. However, it does not state when to use this tool versus alternatives like get_context or search_context, nor does it provide when-not-to-use hints. Sibling names are only available through context signals, not in the description.

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

save_contextB

写入或更新一个板块（会覆盖同名文件）。用于「解析完简历/整理完经历后，把结果存进知识库」。

ParametersJSON Schema

Name	Required	Default
`body`	Yes
`slug`	Yes
`tags`	No
`tier`	No	recruiter
`title`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

The description discloses a key behavioral trait: it will overwrite a file with the same name. However, with no annotations provided, it lacks details about authentication needs, rate limits, or other side effects. The overwrite disclosure is useful but not comprehensive.

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 (two short sentences) and front-loads the action. It efficiently conveys the main purpose and usage context without unnecessary words.

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 5 parameters with no schema descriptions or annotations, the description is insufficient. It does not explain the output schema (though one exists) or cover parameter semantics. The tool's complexity demands more detail for an agent to use it correctly.

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

Parameters1/5

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

Schema coverage is 0%, so the description must explain parameters. It does not describe any of the five parameters (slug, title, body, tags, tier). The mention of 'section' is vague and does not map to parameter meanings. This leaves the agent with no guidance on how to fill parameters.

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: 'write or update a section' and mentions overwriting, which is specific. It also provides a usage scenario ('after parsing resume/organizing experience'), distinguishing it from sibling tools like list_context, get_context, and search_context which are read-only.

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?

The description gives a clear context for use ('after parsing resume/organizing experience, store the result into the knowledge base'), but it does not explicitly state when not to use or mention alternatives. However, the purpose is clear enough that an agent can infer appropriate usage relative to siblings.

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

search_contextC

在所有可见板块里关键词搜索，返回命中板块和上下文片段。

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`viewer_tier`	No		private

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 behavioral traits. It mentions searching 'visible sections,' but fails to state read-only nature, authentication needs, rate limits, or any side effects. The operation's safety is unclear.

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, clear sentence with no unnecessary text. It front-loads the core verb and scope. A small deduction for being in Chinese, which may hinder non-Chinese agents, but the content is efficient.

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 two parameters, no schema descriptions, no annotations, and an output schema not provided, the description is too sparse. It does not explain what 'visible sections' means, how results are sorted, or the role of 'viewer_tier'. The tool's behavior is underspecified.

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?

Schema description coverage is 0%, so the description should explain parameters. It hints at 'query' via 'keyword search' but gives no details on format or constraints. The 'viewer_tier' parameter with default 'private' is completely ignored, leaving its meaning ambiguous.

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 is keyword search across all visible sections, returning hit sections and context snippets. It distinguishes from siblings like list_context and get_context which list or retrieve specific contexts.

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 explicit guidance on when to use this tool versus alternatives such as list_context or get_context. The context of 'search' is implied but not contrasted with other listing/retrieval tools.

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

who_am_iA

一次性返回该 tier 下所有可见内容拼成的完整自我介绍。换新 AI 时，让它调用一次这个工具就「认识你」了。

ParametersJSON Schema

Name	Required	Description	Default
`viewer_tier`	No		private

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/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 discloses that the tool returns all visible content under a tier, implying a read operation, but lacks details on permissions, what 'visible' means, or whether the operation is expensive. Some transparency but insufficient depth.

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 consists of two short, direct sentences with no wasted words. It is front-loaded with the core purpose and immediately clarifies when to use the tool.

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 tool's simplicity and the existence of an output schema, the description is fairly complete. It explains the overall purpose and the parameter's role, though it could briefly mention what 'all visible content' entails. Still, it is adequate for a straightforward tool.

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?

With 0% schema description coverage, the description partially explains the 'viewer_tier' parameter by mentioning '该 tier', indicating it controls which tier's content is included. However, it does not explain possible values or the default behavior, adding some but not complete meaning.

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 returns a complete self-introduction composed of all visible content under a specified tier. The verb '返回' and resource '自我介绍' are specific, and it distinguishes from sibling tools that handle individual context operations.

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?

The description provides a clear use case: when switching to a new AI, call this tool to help it know you. It does not explicitly exclude alternative uses or compare to siblings, but the context is clear.

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.

6 tool updatesv0.1.0Jul 29, 2026
- First observedextract_file
- First observedget_context
- First observedlist_context
- First observedsave_context
- First observedsearch_context
- First observedwho_am_i

Install Server

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

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: list_context shows board titles, get_context retrieves full content, search_context searches, who_am_i returns a compiled self-introduction, save_context writes/updates, and extract_file extracts text from files. No overlap.

Naming Consistency5/5

All tools use snake_case and follow a verb_noun pattern (list_context, get_context, search_context, save_context, extract_file), with who_am_i being a minor but acceptable variant. Very consistent.

Tool Count5/5

6 tools is well-scoped for a personal context server. It covers reading, writing, searching, file ingestion, and a summary tool without being too few or too many.

Completeness4/5

The tool set covers listing, reading, searching, creating/updating, and file extraction. A delete tool is missing, but the domain (personal context boards) may not require it. Minor gap, otherwise complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

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

Tempreon — Personal AI Memory
com.tempreon
Person-owned AI memory that learns, not just stores — portable context for any MCP client.
Knowledge & Memory Autonomous Agents
2
UseMyContext.ai A
io.github.usemycontext
Personal context for AI, written by you and never scraped: your profile and files, any MCP client.
Knowledge & Memory File Systems
132
ContextLattice
io.github.sheawinkler
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Knowledge & Memory Agent Orchestration Autonomous Agents
2153
TabulaOAuth
io.github.nikhilbhima
Cross-AI personal memory. Save once in ChatGPT, recall in Claude, Mistral, Grok, or any MCP client.
Knowledge & Memory
2

Related MCP Servers

CacheTank MCP Serverofficial
Knowledge & Memory Note Taking
July-Blue-Sky-LLC
A
license
A
quality
F
maintenance
Provides persistent personal context (identity, projects, decisions, knowledge) to MCP-compatible AI tools, eliminating the need to re-explain yourself across sessions.
Updated 5 months ago (2026-04-09 05:20 UTC)
2
51
1
MIT
Personal Context Manager
Knowledge & Memory Search
nullptr-z
F
license
Not graded
quality
D
maintenance
Provides persistent personal context storage across AI conversations, allowing AI assistants to remember user preferences, project conventions, and other personal information between sessions.
Updated 5 months ago (2026-04-20 09:34 UTC)
-
personal-context
Knowledge & Memory Note Taking
amr05008
F
license
A
quality
B
maintenance
Enables LLMs to access a user's personal writing context—voice, style, opinions, expertise, projects, and communication patterns—via curated markdown files, helping the LLM match the user's voice when generating written content.
Updated a month ago (2026-08-02 00:34 UTC)
2
3
-
UseMyContext
Knowledge & Memory RAG Systems
usemycontext
A
license
Not graded
quality
B
maintenance
The personal context layer for AI - one user owned profile plus files, read by any MCP client so you never re-introduce yourself.
Updated 12 days ago (2026-08-24 19:59 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/KrystalJin1/personal-context-mcp'

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

🧠 personal-context-mcp

🇨🇳 中文

✨ 这是什么

⏱️ 30 秒看效果

💡 核心理念

📁 目录结构

🚀 快速开始

🔄 它是怎么工作的

🧰 提供的工具

📄 上传简历 / 文件，自动整理进知识库

🧪 测试

🔐 分层可见（tier）

☁️ 留存到 GitHub

🇬🇧 English

✨ What is this

⏱️ See it in 30 seconds

💡 Core ideas

📁 Layout

🚀 Quick start

🧰 Tools

📄 Import a resume, let the AI organize it

🧪 Tests

🔐 Tiered visibility

☁️ Persist to GitHub

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CacheTank MCP Serverofficial

Latest Blog Posts

MCP directory API