Skip to main content
Glama
KenTaniguchi-R

Personal Info MCP

get_personal_info

Retrieve a single personal detail (e.g., email, address) by specifying the exact field name. Avoids reading unrelated data by requesting only the needed field.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other Tools

Latest Blog Posts

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/KenTaniguchi-R/personal-info-mcp'

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