Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Personal Info MCP What's my email address?"
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.
A small MCP server that stores your personal info (name, address, email, professional details, etc.) in an editable JSON file so Claude can pull values instead of you re-typing them every time.
Holds basic identity + professional info only. Do not put financial data or government IDs in here — it is not encrypted.
Runs with uvx — no clone, no virtualenv. uvx
fetches, builds, and caches the server straight from GitHub:
uvx --from git+https://github.com/KenTaniguchi-R/personal-info-mcp personal-info-mcpPin a tag or commit for stability and use uvx --refresh ... to upgrade later:
uvx --from git+https://github.com/KenTaniguchi-R/personal-info-mcp@v0.1.0 personal-info-mcpYou won't usually run this by hand — point your MCP client at it (see below).
Once this is published to PyPI the command simplifies to uvx personal-info-mcp.
Related MCP server: Loc Knowledge Graph Memory Server
Tool | Type | Description |
| read | Get exactly one field by name. No fetch-all mode. |
| read | Keyword search over names/descriptions/tags (no values). Primary way to find a field. |
| read | List tags/categories with a count of fields under each. |
| write | Add/update a field, with optional description and tags. |
| write | Remove a field. |
The split is deliberate for privacy: every read tool exposes only names,
descriptions, and tags so the AI can find the right field, then
get_personal_info returns exactly one value. No single call ever reveals more
than one value, and nothing leaves the machine.
Discovery is search-first by design: there is no "list every field" tool, so
no call can dump the whole catalog into the AI's context. Use list_tags to
orient, search_personal_info to find a field (results are bounded by limit,
relevance-ranked), then get/delete it. A get/delete on a name that
doesn't exist returns a few near-match suggestions — never the full list — so a
typo can't flood context no matter how many fields you store.
Your info lives in a JSON file in your per-user data directory, created on first
write with owner-only (0600) permissions:
OS | Default path |
macOS |
|
Linux |
|
Windows |
|
Set the PERSONAL_INFO_PATH environment variable to keep it somewhere else. Each
field is an object with a value, a short non-secret description, and optional
tags (the description and tags are shown in discovery/search to help pick the
right field — never put secrets in them):
{
"full_name": { "value": "Jane Doe", "description": "Legal full name", "tags": ["identity"] },
"email": { "value": "jane@example.com", "description": "Primary email", "tags": ["contact"] },
"amex_main": { "value": "...", "description": "Primary credit card", "tags": ["payment", "card"] }
}Legacy flat { "field": "value" } files are still read (description/tags default
to empty) and upgraded to the object form on the next write.
claude mcp add personal-info -- uvx --from git+https://github.com/KenTaniguchi-R/personal-info-mcp personal-info-mcpOr add it to your MCP client config (e.g. ~/.claude.json mcpServers) by hand:
{
"mcpServers": {
"personal-info": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/KenTaniguchi-R/personal-info-mcp",
"personal-info-mcp"
]
}
}
}Mark set_personal_info and delete_personal_info as confirm-required (writes);
get_personal_info, search_personal_info, and list_tags are safe to
auto-allow (reads).
Add the same block to claude_desktop_config.json and restart Claude Desktop
(macOS: ~/Library/Application Support/Claude/, Windows:
%APPDATA%\Claude\):
{
"mcpServers": {
"personal-info": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/KenTaniguchi-R/personal-info-mcp",
"personal-info-mcp"
]
}
}
}Clone and work against the source:
git clone https://github.com/KenTaniguchi-R/personal-info-mcp
cd personal-info-mcp
uv sync
uv run mcp dev personal_info_mcp/server.py # opens the MCP Inspector
uv run pytest -v # run testsTo point a client at your working copy instead of the GitHub version, use uv run against the checkout:
{
"mcpServers": {
"personal-info": {
"command": "uv",
"args": ["run", "--directory", "/path/to/personal-info-mcp", "personal-info-mcp"]
}
}
}Delete a personal-info field. WRITE — confirm with the user first.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the write/destructive nature ('WRITE') and the need for user confirmation. No annotations exist, so the description carries full burden and does so effectively.
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?
Extremely concise: one sentence and a warning. The critical usage note is front-loaded, making it immediately actionable.
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?
For a simple delete tool with one parameter and an output schema, the description covers purpose and behavioral guidance well. However, missing parameter explanation reduces 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?
The single parameter 'field' is not described in either the schema (0% coverage) or the description. The agent has no guidance on valid values or format, which is a significant gap for a required parameter.
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?
Explicitly states 'Delete a personal-info field', clearly identifying the action (delete) and the resource (personal-info field). Differentiates from siblings like get, list, search, and set.
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?
Includes 'WRITE — confirm with the user first', providing explicit guidance that it is a mutating operation and requires user confirmation, which helps the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one stored personal-info value by exact field name.
Pass a single field name (e.g. "email", "home_address") to get that one value. There is intentionally no "fetch everything" mode: use search_personal_info (or list_tags) to discover the field you need, then request only that one so no unrelated personal data is ever read. Use this instead of asking the user to type their personal details.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the intentional lack of a 'fetch everything' mode and the privacy benefit of reading only one field. Could mention that it is a read operation with no side effects, but overall sufficient.
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, well-structured, and every sentence adds value. No fluff.
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?
Given the tool's simplicity (one parameter, no annotations, output schema present), the description is complete. It explains the input and usage intent adequately.
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?
The schema has 0% coverage, but the description adds meaning by giving examples ('email', 'home_address') and specifying that the field name must be exact. This compensates for the bare schema.
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 it returns one stored personal-info value by exact field name. It distinguishes from siblings by explicitly noting the absence of a 'fetch everything' mode and mentioning alternative tools for discovery.
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?
Explicitly says to use search_personal_info or list_tags to discover the field first, and to use this tool instead of asking the user to type personal details. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tags/categories in use, with a count of fields under each.
Use this to orient in a large store: pick a tag, then call search_personal_info with it to see fields in that category. No values are returned, and the output is bounded by the number of tags, not fields.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: no values returned, output bounded by tag count. Missing explicit statement of read-only nature, but implied by context.
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, front-loaded with purpose, no wasted words. Perfectly concise for the tool's simplicity.
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?
Given 0 params and presence of output schema, the description is complete: explains output structure (counts, no values, bounded), usage context, and ties to sibling tool. No gaps.
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?
With 0 parameters and schema coverage at 100%, the description adds no parameter details, but baseline is 4. No need for additional semantics.
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 lists tags/categories with counts of fields, using a specific verb and resource. It distinguishes from sibling tools like search_personal_info by focusing on tags rather than personal info fields.
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?
Explicitly advises when to use (orienting in large store) and provides a workflow: pick a tag then call search_personal_info. Also clarifies what is not returned (no values, bounded output).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search fields by keyword over names, descriptions, and tags (no values).
Returns the best-matching "field — description" lines, most relevant first,
capped at limit. This is the primary way to discover a field: results
stay bounded no matter how many fields exist. Then call get_personal_info
with the single field you want. Never returns values.
The field name is an internal identifier for get_personal_info only. When replying to the user, refer to information by its description in natural language — never echo the raw field key. Don't proactively volunteer other stored fields the user didn't ask about.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: searches over names/descriptions/tags, returns capped 'field — description' lines, never returns values, results ordered by relevance, and internal field name usage. It also provides user-facing instructions.
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 well-structured, front-loads the purpose, and each sentence adds value. It is slightly lengthy but clear. Could be trimmed slightly without loss.
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?
Given the presence of an output schema, the description doesn't need to detail return format. It covers search scope, non-return of values, sibling tool usage, and user-facing behavior. Complete 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 0%, so description compensates by explaining 'query' as a keyword search and 'limit' as a cap (default 20). It adds context about search scope but doesn't specify exact query syntax. Given two simple parameters, this is sufficient.
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 it searches fields by keyword over names, descriptions, and tags, and explicitly distinguishes itself from sibling tools like get_personal_info (which retrieves a single field) and set_personal_info. It sets clear expectations that it does not return values.
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 identifies this as the primary discovery tool and instructs calling get_personal_info after. It advises not to volunteer other fields. While it lacks an explicit 'when not to use', the context with siblings makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update a personal-info field. WRITE — confirm with the user first.
Optionally pass a short, non-secret description and a list of tags
(both shown in discovery/search to help pick the right field — never put
secrets in them). Omitting description keeps any existing one; omitting
tags keeps existing tags (pass [] to clear). Example:
set_personal_info("amex_main", "...", "Primary card", ["payment", "card"]).
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| value | Yes | ||
| description | No | ||
| tags | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description sufficiently discloses behavioral traits: it's a write operation, requires user confirmation, explains the side effects of omitting optional parameters (keeps existing values) and how to clear tags (pass []), and includes a warning against putting secrets in the description or tags. An example further clarifies usage.
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, starting with the core purpose and then adding necessary detail. It uses clear language and provides an example. Minor redundancy in warning about secrets ('non-secret' and 'never put secrets') but overall well-structured and efficient.
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?
Given the existence of an output schema (not shown) and the context signals, the description adequately covers the tool's purpose, parameter behavior, and usage guidelines. It does not need to explain return values since an output schema exists. It is sufficiently complete for an agent to use the tool correctly.
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?
The input schema has 0% description coverage, so the description compensates well. It explains that field and value are required, describes the optional description and tags, clarifies their behavior when omitted (keeps existing) or cleared ([]), and warns about secrets. The example concretely illustrates parameter order and values.
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 explicitly states the tool adds or updates a personal-info field. This clearly distinguishes it from sibling tools like delete_personal_info, get_personal_info, list_tags, and search_personal_info, which handle deletion, retrieval, listing, and searching respectively.
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 highlights that this is a write operation requiring user confirmation ('WRITE — confirm with the user first'). While it doesn't explicitly state when not to use it, the context of siblings implies read-only alternatives. The guidance for confirming with the user is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: delete, get, list tags, search, and set. No two tools overlap in functionality.
All tools follow a consistent verb_noun pattern with snake_case (e.g., delete_personal_info, list_tags). No mixing of conventions.
5 tools is well-scoped for managing personal info fields. Covers all necessary operations without excess.
Full lifecycle coverage: set (create/update), get (read), search (discovery), delete, and list_tags (organization). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal CRM for Claude. Contacts live as plain-text files in your own Google Drive.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Your professional network in Claude — search contacts, log notes, and send warm intros.
Gives your AI assistant persistent memory and intelligence about your work patterns.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/KenTaniguchi-R/personal-info-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
