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 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 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.

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 a personal-info field. WRITE — confirm with the user first.