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., "@Chen's AI Copy summarize my recent work experience and project learnings"
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.
Personal digital twin MCP (Model Context Protocol) server. Provides Chen's experience, skills, resume preferences, learnings, and interested companies to AI assistants across projects.
Repo: github.com/shenchensucc/chens-ai-copy
get_context — Retrieve experience, skills, preferences, learnings, or interested companies
add_learning — Record new learnings, patterns, or insights from project work
update_preference — Update resume format, communication style, or other preferences
add_interested_company — Add companies to track for job applications
Related MCP server: Mono Memory MCP
git clone https://github.com/shenchensucc/chens-ai-copy.git
cd chens-ai-copy
npm install
npm run buildAdd to ~/.cursor/mcp.json (Windows: C:\Users\<you>\.cursor\mcp.json or Cursor Settings > MCP):
{
"mcpServers": {
"chens-ai-copy": {
"command": "node",
"args": ["C:/path/to/chens-ai-copy/dist/index.js"]
}
}
}Use the full path to your cloned chens-ai-copy folder.
The MCP uses sync-and-run.ps1 which runs git pull before starting, so you always get the latest when opening Cursor. Ensure the MCP config points to the script:
{
"chens-ai-copy": {
"command": "powershell",
"args": ["-NoProfile", "-ExecutionPolicy", "Bypass", "-File", "D:/2026/2026-03 Chens-ai-copy/sync-and-run.ps1"]
}
}Clone: git clone https://github.com/shenchensucc/chens-ai-copy.git D:\2026\2026-03 Chens-ai-copy
Run: cd D:\2026\2026-03 Chens-ai-copy && npm install && npm run build
Add the MCP config above to ~/.cursor/mcp.json (adjust path if different)
File | Content |
| Resume format, communication style, cover letter structure |
| Work history, education, certifications |
| Technical, soft, and domain skills |
| Project-derived learnings and patterns |
| Companies and roles of interest |
When working in any project, ask the AI to:
"Add this to my digital twin: [learning]"
"Remember that I prefer [preference]"
"Update my context with what we learned from this project"
The AI will call add_learning or update_preference to keep your context current.
CHENS_AI_COPY_DATA_PATH — Override data directory (default: ./data relative to package)
git pull # get updates
git push # push changesMIT
Add a company Chen is interested in applying to or working with.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Company name | |
| sector | No | Optional: industry sector | |
| notes | No | Optional: notes | |
| rolesOfInterest | No | Optional: roles of interest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description fails to disclose critical behavioral aspects such as whether this creates a persistent record, how it handles duplicates, or what permissions are required. It only states high-level intent without explaining side effects, idempotency, or success conditions that an agent needs to invoke the tool properly.
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 a single, efficiently constructed sentence that front-loads the verb and contains zero redundant words. It delivers the core purpose immediately without unnecessary filler or tautology.
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?
While the description adequately covers the tool's purpose and leverages complete schema documentation, it lacks behavioral details expected for a mutation tool given the absence of annotations and output schema. It omits information about return values, error states, or the persistence model that would help an agent understand the full operation context.
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 100% schema description coverage, the parameter names and types are self-documenting; the description adds minimal semantic value beyond implying the domain context for 'rolesOfInterest'. It meets the baseline expectation but does not elucidate parameter relationships, validation constraints, or format requirements beyond what the schema already provides.
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 action ('Add') and object ('a company'), with specific scope indicating this is for Chen's job search interests. It effectively distinguishes this from sibling tools like `add_learning` through the distinct resource type and domain context, though it could specify what system the company is being added to.
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 implies usage context ('interested in applying to or working with') suggesting job search tracking scenarios. However, it lacks explicit guidance on when to prefer this over `get_context` or `update_preference`, and does not address prerequisites such as whether the company already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a learning, pattern, or insight to Chen's context. Use when Chen adopts a new approach, learns something from a project, or asks to remember something for future use.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The learning or insight to remember | |
| source | No | Optional: project or context where this was learned | |
| category | No | Optional: e.g. 'resume', 'coding', 'process' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. 'Remember something for future use' implies persistence and retrieval capability, establishing this as a memory tool. However, lacks details on idempotency, storage limits, conflict resolution, or return value confirmation.
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 with zero waste. First sentence establishes purpose immediately; second provides usage contexts. Every word earns its place.
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?
Appropriate for a 3-parameter tool with no output schema. Covers purpose, usage semantics, and parameter intent. Could be improved by noting persistence guarantees or what constitutes a successful operation, but adequate for the complexity level.
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 100%, establishing baseline 3. Description contextualizes content as 'learning' or 'approach' and mentions 'project' which aligns with source parameter semantics. Does not add syntax details or validation constraints beyond 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?
Specific verb 'Add' with clear resource 'learning, pattern, or insight to Chen's context'. Distinguishes from sibling get_context (add vs retrieve), update_preference (learnings vs preferences), and add_interested_company (learnings vs companies) by scope and resource type.
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?
Provides explicit positive usage scenarios: 'when Chen adopts a new approach,' 'learns something from a project,' or 'asks to remember something.' Lacks explicit 'when not to use' or named alternatives, but clear contextual boundaries are established.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Chen's full personal context: experience, skills, resume preferences, learnings, and interested companies. Use when starting a new project or when you need to understand Chen's background and preferences.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional: 'all' | 'experience' | 'skills' | 'preferences' | 'learnings' | 'companies'. Default: all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Expands 'context' into concrete data categories but omits data source, freshness, return format structure, and cache behavior. Justifies a 3 by defining what constitutes 'context' beyond the tool name.
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, zero waste. First sentence defines scope with enumeration; second gives usage triggers. Front-loaded with action and resource. Every clause earns its place.
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?
Simple read tool with one optional parameter. Without output schema or annotations, description adequately covers return categories but lacks return structure and data provenance. Sufficient for the complexity level but gaps remain.
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 100% with clear enum documentation. Description lists the section values ('experience', 'skills', etc.) in prose but doesn't explicitly reference the 'section' parameter or explain filtering syntax. Baseline 3 appropriate given schema does heavy lifting.
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?
Uses specific verb 'Get' with explicit resource 'Chen's full personal context'. Enumerates specific components (experience, skills, resume preferences, learnings, interested companies) that distinguish this read operation from write-oriented siblings (add_interested_company, add_learning, update_preference).
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?
Provides explicit when-to-use guidance ('when starting a new project' and 'when you need to understand Chen's background'). Lacks explicit when-not-to-use or named alternatives, but clear positive guidance earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a preference in Chen's context. Use when Chen expresses a new preference (e.g. resume format, communication style, tool choice).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Preference key, e.g. 'resumeFormat.style' or 'communication.tone' | |
| value | Yes | The value to set (will be parsed as JSON if possible) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States operation occurs 'in Chen's context' but fails to disclose mutation semantics (create vs. overwrite), persistence behavior, or side effects. The JSON parsing behavior mentioned in schema parameter description is not reinforced in main description.
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 with zero redundancy. First sentence establishes purpose; second establishes trigger condition with examples. Perfectly front-loaded and appropriately sized for tool complexity.
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?
With no annotations and no output schema, description covers basic operation adequately but omits persistence model, overwrite behavior, and relationship to get_context sibling (which presumably reads these preferences). Adequate for simple key-value tool but has 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?
Schema coverage is 100%, establishing baseline of 3. Description adds domain context through examples (resume format, communication style) but does not add syntax guidance or value constraints beyond what's in the schema. The dot-notation schema hint exists only in parameter description, not main description.
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?
Clear specific verb ('Update') + resource ('preference in Chen's context'). Explicitly distinguishes from sibling tools: add_interested_company and add_learning focus on adding specific entities, while get_context retrieves data; this tool specifically handles user preference updates.
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 states when to use: 'Use when Chen expresses a new preference' with concrete examples (resume format, communication style, tool choice). Lacks explicit 'when not to use' or named alternative tools, though the scope is narrow enough to be clear.
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 with no overlap: adding companies, adding learnings, retrieving full context, and updating preferences. The descriptions explicitly differentiate their use cases, making it impossible to confuse them.
The tools follow a consistent verb_noun pattern (add_interested_company, add_learning, get_context, update_preference), with all using snake_case. The only minor deviation is that 'get_context' uses 'get' while others use 'add' or 'update', but this is semantically appropriate and still maintains readability.
With 4 tools, this server is well-scoped for managing personal context and preferences. Each tool serves a specific function in this domain, and there are no extraneous or missing tools for the apparent purpose of maintaining Chen's background information.
The tool set covers the core CRUD operations for Chen's context: adding items (companies/learnings), retrieving context, and updating preferences. A minor gap is the lack of deletion tools (e.g., remove_company or remove_learning), but agents can likely work around this by updating preferences or context as needed.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Person-owned AI memory that learns, not just stores — portable context for any MCP client.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shenchensucc/chens-ai-copy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
