Use mcp-me v0.6.0 to Share One Local AI Profile Across MCP Clients

TL;DR If you use more than one MCP-compatible AI client, repeating your background in every tool is tedious and easy to get wrong. mcp-me v0.6.0 gives you one local profile directory, a YAML configuration file, and an MCP server that clients can read. This tutorial creates the profile, validates it, configures the same server for Cursor, VS Code, and Windsurf, and explains where Claude Desktop fits. The setup uses the published mcp-me@0.6.0 package, not an unreleased checkout. You need: Node.js 20 or later. The package declares node >=20.0.0 in its release metadata. npm and a terminal. One MCP-compatible client such as Cursor, VS Code with GitHub Copilot, Windsurf, or Claude Desktop. The project is open source under the MIT license. The v0.6.0 release is the stable reference for this walkthrough, and the package manifest records the version and Node.js requirement. You can run the CLI without a global installation through npx. This keeps the example tied to the exact version used in the tutorial. npx --yes mcp-me@0.6.0 init npx --yes mcp-me@0.6.0 validate With no directory argument, v0.6.0 uses ~/.mcp-me as the default profile location. The init command creates the YAML templates, .mcp-me.yaml, and agent instruction files. The validate command checks the profile YAML files against the project's schemas. The command output should end with a successful validation message for the profile files. In a clean smoke test, the release created 11 files and validated identity, career, skills, interests, personality, goals, projects, and FAQ data. Now inspect the generated configuration: cat ~/.mcp-me/.mcp-me.yaml On Windows PowerShell, use this equivalent command: Get-Content "$HOME\.mcp-me\.mcp-me.yaml" The file separates data generators from live plugins. Start with a small configuration and replace the example values with your own public handles: generators: github: your-username devto: your-username plugins: github: enabled: true username: your-username The configuration is not your profile data. It tells mcp-me which sources to use when it generates profile files and which live plugins should be available to the server. Keep the generated YAML files reviewable, and validate after editing. After editing .mcp-me.yaml, run the generator: npx --yes mcp-me@0.6.0 generate npx --yes mcp-me@0.6.0 validate The v0.6.0 README documents username-based generators and the default profile path. Many public sources do not need API keys, but that is source-dependent. A provider can still require authentication, rate limits, or a local export. Treat each generated file as data to review before making it available to an assistant. If you want an isolated profile for a project or experiment, pass a directory explicitly instead of changing the default: npx --yes mcp-me@0.6.0 init ./my-ai-profile npx --yes mcp-me@0.6.0 validate ./my-ai-profile npx --yes mcp-me@0.6.0 generate ./my-ai-profile This explicit path is useful for testing because it makes the data boundary obvious. It also lets you keep separate profiles for work and personal use. The important idea is that every client points to the same command and profile directory. The server reads the profile when it starts, so the clients do not need separate copies of your YAML files. The simplest cross-client command is: npx -y mcp-me serve For Windsurf, add an entry to ~/.codeium/windsurf/mcp_config.json: { "mcpServers": { "me": { "command": "npx", "args": ["-y", "mcp-me", "serve"] } } } For Cursor, place the same server entry in .cursor/mcp.json in a project, or in the client configuration used for global servers: { "mcpServers": { "me": { "command": "npx", "args": ["-y", "mcp-me", "serve"] } } } VS Code uses a different top-level key. In .vscode/mcp.json, use servers: { "servers": { "me": { "command": "npx", "args": ["-y", "mcp-me", "serve"] } } } These client examples are taken from the v0.6.0 README configuration section. Claude Desktop can use the .mcpb asset attached to the v0.6.0 GitHub release, or the manual MCP configuration documented by the project. Before connecting a client, ask the CLI for help and validate the profile again: npx --yes mcp-me@0.6.0 --help npx --yes mcp-me@0.6.0 validate Then start the server in a terminal: npx --yes mcp-me@0.6.0 serve An MCP client normally launches this process itself over standard input and output. The useful verification is therefore client-side: connect the me server, ask the client to read a profile resource, and confirm that the answer matches the YAML you reviewed. Do not treat a successful process launch as proof that every generator or plugin works. If you need to make the profile location explicit, set MCP_ME_PROFILE_DIR in the client process environment or pass a directory to the serve command. The release README documents both options. The profile files and the .mcp-me.yaml configuration form a local source of context. The MCP server exposes that context through the protocol, while each client remains responsible for deciding when to read it. This is different from copying a long instruction block into every client: the data has one canonical location, and changes can be reviewed with normal file tools. The design also leaves a useful boundary between generated data and live integrations. Generated YAML can be inspected before use. Plugins can provide current values when an assistant queries them. That separation makes it easier to disable a plugin, remove a field, or keep a sensitive category out of a profile. npx GUI applications may not inherit the same PATH as your terminal. Check the client documentation for environment configuration, or use the absolute path to your Node.js installation. The error is a process discovery problem, not a profile validation failure. Run validate with the profile directory and read the first reported file. Fix the schema or value, then run validation again. Do not connect an unvalidated profile and assume the client will explain the problem. Generators depend on the source's public API, feed, or export format. A valid local profile does not prove that a remote source returned complete data. Review the generated file and consult the source-specific documentation before relying on it. The project is designed around local YAML files, but any MCP client that can read those files may place their contents into model context. Do not put passwords, private keys, access tokens, or secrets in the profile. Use the project's documented plugin settings and your operating system's file permissions. The MIT license and local execution do not constitute a security guarantee. The tutorial also uses the stable v0.6.0 release. The repository's default branch may contain newer or unreleased behavior, so check the current changelog before copying commands into a new environment. mcp-me globally? No. npx --yes mcp-me@0.6.0 is enough for the commands above. A global npm installation is convenient for repeated use, but pinning the version makes a tutorial and a reproducible check clearer. Yes. Pass an explicit directory or set MCP_ME_PROFILE_DIR for a client process. Use separate profiles when the audiences or sensitivity of the data differ. mcp-me remember previous conversations? No. It exposes profile data and configured live resources through MCP. Conversation history, model behavior, and client-side context policies remain separate concerns. Use one reviewed profile directory as the shared context layer, validate it after every edit, and point each MCP client at the same mcp-me serve command. Start with public, low-risk fields. Add generators and plugins only when you understand what data they read and what the client can send to a model. What is the first profile category you would keep local and shared across your AI tools: skills, projects, career history, or something else? AI assistance disclosure: I used AI assistance to organize and edit this tutorial. The commands, version claims, configuration examples, and smoke-test result were checked against the mcp-me v0.6.0 release and its primary project documentation.