Personal Context MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between batch_get_personal_info and list_available_personal_info, as both involve listing or retrieving personal info categories. However, their primary functions (retrieving data vs. listing available categories) are differentiated enough to avoid major confusion. The OTP-related tools (setup_otp, verify_otp, lock_otp, disable_otp, otp_status) are clearly distinct from the personal info management tools.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures. Personal info tools use verbs like get, save, delete, update, and list, while OTP tools use verbs like setup, verify, lock, disable, and status. This consistency makes the tool set predictable and easy to understand.
Tool Count5/5
With 10 tools, the count is well-scoped for managing personal information and OTP security. It covers core operations (CRUD for personal data, OTP lifecycle) without being excessive or too sparse. Each tool serves a clear purpose, and there are no redundant or trivial additions.
Completeness4/5
The tool set provides strong coverage for personal info management (create/retrieve via batch, update, delete, list available) and OTP security (setup, verify, lock, disable, status). A minor gap is the lack of a tool for creating new personal info from scratch (e.g., create_personal_info), as batch_save_personal_info implies updating existing data, but agents can work around this using batch operations. Overall, it supports most workflows effectively.
Average 3/5 across 10 of 10 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't indicate whether this is a read-only or destructive operation, what permissions might be required, whether changes are reversible, what happens on success/failure, or any rate limits. For a mutation tool with zero annotation coverage, this is completely inadequate.
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 extremely concise - just three words. While this is efficient, it's under-specified rather than appropriately concise. Every word earns its place, but there simply aren't enough words to provide meaningful guidance. The structure is front-loaded but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does beyond the obvious, provides no behavioral context, offers no parameter guidance, and gives no usage instructions. This leaves the agent with insufficient information to use the tool effectively.
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 schema has 0% description coverage, meaning all 4 parameters are completely undocumented in the schema. The description provides no information about what 'category', 'subcategory', 'content', or 'tags' mean, their expected formats, or how they relate to 'personal information'. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update existing personal information' is a tautology that essentially restates the tool name 'update_personal_info' and title 'Update Personal Information'. It provides no specific details about what 'personal information' entails or how the update operation works. While it does include the verb 'update', it lacks any distinction from sibling tools like 'batch_save_personal_info' or 'delete_personal_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or exclusions. Given sibling tools like 'batch_save_personal_info' and 'delete_personal_info', the agent has no information about when this single update tool is preferable to batch operations or when deletion might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers no details. It does not address critical aspects like required permissions, whether deletion is permanent or reversible, rate limits, or response format, making it inadequate for a destructive operation.
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 extremely concise with a single sentence, 'Delete specific personal information', which is front-loaded and wastes no words. However, this brevity contributes to underspecification rather than effective communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, 0% schema coverage, no output schema, and multiple sibling tools, the description is severely incomplete. It fails to provide necessary context for safe and correct usage, such as behavioral traits, parameter meanings, or differentiation from alternatives.
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%, so the description must compensate but adds no information about the parameters 'category' and 'subcategory'. It does not explain what these parameters represent, their expected values, or how they affect the deletion process, leaving them undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete specific personal information' restates the tool name/title with minimal elaboration, making it tautological. While it includes the verb 'delete' and resource 'personal information', it lacks specificity about what constitutes 'personal information' or how deletion occurs, failing to distinguish meaningfully from sibling tools like 'update_personal_info' or 'batch_save_personal_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparisons to sibling tools such as 'update_personal_info' or 'list_available_personal_info', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'within current permissions,' which adds some context about access, but lacks details on rate limits, pagination, response format, or whether it's read-only. For a tool with zero annotation coverage, this is insufficient.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes to understanding the tool's function, making it appropriately concise.
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 the complexity of personal information tools, no annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't explain what 'personal information' includes, how results are returned, or how it differs from siblings, leaving significant gaps for an AI agent.
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?
The schema has 1 parameter with 0% description coverage, and the tool description doesn't mention any parameters. The description fails to compensate for the schema's lack of documentation, leaving the 'category_filter' parameter's purpose and usage unexplained.
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 verb ('List') and resource ('all available personal information'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'batch_get_personal_info' which might have overlapping functionality, preventing a perfect score.
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?
The description provides minimal guidance by mentioning 'within current permissions,' which hints at access control but doesn't specify when to use this tool versus alternatives like 'batch_get_personal_info' or 'update_personal_info.' No explicit when/when-not rules or sibling comparisons are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions output presentation (QR code/backup codes in app panel or structured result) but omits critical details like whether this is a one-time setup, if it overwrites existing OTP, required permissions, or error conditions. For a security-related tool, this is a significant gap.
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 appropriately brief (two sentences) and front-loaded with the core purpose. The second sentence adds necessary context about output handling without redundancy, though it could be slightly more streamlined.
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?
For a security setup tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral implications (e.g., irreversible changes), error handling, and how the output integrates with sibling tools. The context about client capabilities is helpful but insufficient for full understanding.
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?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.
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 verb ('Set up') and resource ('One-Time Password for encrypted personal data'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'lock_otp' or 'disable_otp', which would require more specific language about initial setup versus management.
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?
The description mentions client capabilities (MCP App-capable vs. others) but provides no guidance on when to use this tool versus alternatives like 'verify_otp' or 'otp_status'. It lacks explicit when/when-not instructions or prerequisites for setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions disabling 'authentication and encryption for personal data,' which implies a security-related mutation, but doesn't specify critical details like whether this action is reversible, what permissions are required, or potential side effects (e.g., data exposure). This is inadequate for a tool that likely alters security settings.
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 a single, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficient, making it easy for an agent to parse quickly.
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 the complexity of disabling OTP (a security mutation with no annotations or output schema), the description is insufficient. It lacks details on behavior, outcomes, or error conditions, which are crucial for safe invocation. The agent is left with significant gaps in understanding how to use this tool effectively.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter-specific information, but this is acceptable given the lack of inputs. A baseline of 4 is appropriate as the description doesn't need to compensate for any parameter gaps.
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 ('Disable') and the target ('OTP authentication and encryption for personal data'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'lock_otp' or 'otp_status', which would require more specific context about how 'disable' differs from 'lock' or status checking.
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?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used instead of 'lock_otp' for permanent deactivation, or what prerequisites might be needed (e.g., OTP must be enabled first). This leaves the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions efficiency but fails to disclose critical traits: whether this is a write operation (implied by 'Save'), what permissions are required, if it's idempotent, error handling for partial failures, or response format. For a mutation tool with zero annotation coverage, this is a significant gap.
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 appropriately sized with two concise sentences that are front-loaded: the first states the core purpose, and the second adds efficiency context. Every sentence earns its place without redundancy or fluff.
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 the complexity (a mutation tool with nested array parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error cases, or return values, leaving significant gaps for agent understanding.
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 must compensate for undocumented parameters. It only mentions 'multiple pieces of personal information' without explaining the 'items' array structure, required fields like 'category' and 'content', or optional ones like 'tags'. This adds minimal value beyond the schema's property names.
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 ('Save multiple pieces of personal information') and resource ('personal information'), making the purpose evident. It distinguishes from individual save operations by emphasizing batch efficiency, though it doesn't explicitly differentiate from sibling tools like 'update_personal_info' or 'list_available_personal_info'.
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 clear context for when to use this tool ('More efficient than making multiple individual save requests'), guiding the agent toward batch operations over individual ones. However, it doesn't specify when NOT to use it (e.g., for single items) or mention alternatives like 'update_personal_info' for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool does (check status) but doesn't disclose behavioral traits like whether this requires authentication, what permissions are needed, rate limits, or what specific information is returned. For a status-checking tool with zero annotation coverage, this leaves significant gaps in understanding its operational characteristics.
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 perfectly concise with a single, clear sentence that states exactly what the tool does. Every word earns its place, and the information is front-loaded with no unnecessary elaboration. The structure is optimal for a zero-parameter status-checking tool.
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?
Given the tool's complexity (simple status check with no parameters) and lack of annotations/output schema, the description is minimally adequate. It states the purpose but doesn't provide enough context about what 'OTP configuration status' entails or what 'OTP verification is required' means in practice. For a tool that likely returns structured status information, more detail about the return format would be helpful.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it doesn't need to compensate for any schema gaps. The description focuses correctly on the tool's purpose rather than parameter details.
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 tool's purpose with specific verbs ('check') and resources ('OTP configuration status', 'OTP verification requirement'). It distinguishes from siblings like 'disable_otp', 'lock_otp', 'setup_otp', and 'verify_otp' by focusing on status checking rather than modification or verification actions. However, it doesn't explicitly contrast with 'list_available_personal_info' which might also provide OTP-related information.
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 implies usage context (checking OTP configuration and verification requirements) but doesn't provide explicit guidance on when to use this tool versus alternatives. No when-not-to-use scenarios or specific prerequisites are mentioned. The tool's purpose suggests it should be used before OTP-related operations, but this isn't stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions that verification is required for accessing encrypted data, but doesn't disclose behavioral traits like what happens on failure (e.g., lockout), rate limits, authentication needs beyond the token, or whether this is a one-time or session-based verification. For a security-critical tool with zero annotation coverage, this is inadequate.
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 two concise sentences with zero waste. It's front-loaded with the core purpose and efficiently adds the usage context. Every sentence earns its place by providing essential information.
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?
Given the complexity (security verification tool), lack of annotations, and no output schema, the description is incomplete. It covers the purpose and basic usage but misses critical behavioral details (e.g., success/failure outcomes, security implications). For a tool with 3 parameters and no structured safety hints, this is minimally adequate but leaves significant gaps.
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?
Schema description coverage is 67% (2 out of 3 parameters have descriptions). The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain token format or userId usage). With moderate schema coverage, the baseline is 3 as the description doesn't compensate for the gap but doesn't worsen it either.
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 tool's purpose as 'Verify an OTP token to access encrypted personal data', which is specific (verb+resource) and distinguishes it from siblings like 'setup_otp' or 'disable_otp'. However, it doesn't explicitly differentiate from 'otp_status' which might check status rather than verify.
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 clear context: 'Required before reading encrypted information', which indicates when to use this tool (as a prerequisite for accessing data). It doesn't specify when not to use it or name alternatives, but the context is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 retrieval is 'based on category and current permissions,' adding context about access control. However, it lacks details on behavioral traits such as rate limits, response format, error handling, or whether this is a read-only operation (implied by 'retrieve' but not explicit). The description adds some value but is incomplete for a tool handling sensitive personal data.
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 front-loaded with the core purpose in the first sentence, followed by elaboration and a prerequisite. It uses two sentences efficiently, with no redundant information. However, the second sentence is slightly verbose ('you can get a wide range of information... and even more'), which could be tightened for better conciseness.
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?
Given no annotations, no output schema, and 50% schema description coverage, the description is moderately complete. It covers purpose and prerequisites well but lacks details on behavioral aspects (e.g., permissions, data sensitivity, response structure) and doesn't fully compensate for the schema gaps. For a tool handling personal information, more context on security and output would improve completeness.
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?
Schema description coverage is 50%, with one parameter ('has_list_available_personal_info') having a description. The description mentions 'category' and 'subcategory' indirectly through examples but doesn't explain parameter semantics beyond what the schema provides. It adds minimal value over the schema, such as hinting at categories like 'personal, pets,' but doesn't detail format or constraints, so baseline 3 is appropriate given partial schema coverage.
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 tool's purpose: 'Retrieve multiple categories of personal information in a single request.' It specifies the verb 'retrieve' and resource 'personal information,' with examples like 'personal, pets, family, friends, work, etc.' However, it doesn't explicitly differentiate from siblings like 'list_available_personal_info' beyond mentioning it as a prerequisite, missing a direct comparison of retrieval vs. listing.
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?
The description provides explicit usage guidance: 'You must list once all the categories with the list_available_personal_info tool before using this tool to understand what you can get.' It names a specific alternative tool and states a clear prerequisite, though it doesn't mention other siblings like 'batch_save_personal_info' or 'update_personal_info' for context on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: the action is immediate, it blocks data access, and requires verify_otp for re-access. However, it lacks details on permissions, rate limits, or error conditions, preventing a perfect score.
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 two sentences with zero waste: the first states the action and effect, the second explains the consequence and alternative. It is front-loaded with the core purpose and efficiently structured.
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 complexity (a security action with no parameters), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, and behavior, but lacks details on response format or error handling, which could be useful for an agent.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention parameters, which is appropriate. Baseline is 4 for 0 parameters, as it avoids unnecessary details.
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 specific action ('immediately lock') and target resource ('current OTP session'), distinguishing it from siblings like disable_otp, verify_otp, and otp_status. It explicitly mentions the effect ('block access to encrypted personal data'), making the purpose unambiguous and distinct.
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 clear context for when to use this tool: to lock the OTP session and block data access. It mentions the alternative verify_otp for re-verification, but does not explicitly state when not to use it (e.g., vs. disable_otp for permanent deactivation) or other exclusions, keeping it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![personal-context-mcp MCP server](https://glama.ai/mcp/servers/matipojo/personal-context-mcp/badges/card.svg)](https://glama.ai/mcp/servers/matipojo/personal-context-mcp)

Score Badge

Copy to your README.md:

[![personal-context-mcp MCP server](https://glama.ai/mcp/servers/matipojo/personal-context-mcp/badges/score.svg)](https://glama.ai/mcp/servers/matipojo/personal-context-mcp)

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

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