Skip to main content
Glama
KenTaniguchi-R

Personal Info MCP

by KenTaniguchi-R
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PERSONAL_INFO_PATHNoOptional path to the personal info JSON file. If not set, defaults to OS-specific user data directory.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_personal_infoA

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.

search_personal_infoA

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.

list_tagsA

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.

set_personal_infoA

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"]).

delete_personal_infoA

Delete a personal-info field. WRITE — confirm with the user first.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: delete, get, list tags, search, and set. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case (e.g., delete_personal_info, list_tags). No mixing of conventions.

Tool Count5/5

5 tools is well-scoped for managing personal info fields. Covers all necessary operations without excess.

Completeness5/5

Full lifecycle coverage: set (create/update), get (read), search (discovery), delete, and list_tags (organization). No obvious gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources