DEV Community

Fernando Paladini
Fernando Paladini

Posted on

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

#ai #mcp #tutorial #cli

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.

Prerequisites

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.

Create and validate one profile

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

On Windows PowerShell, use this equivalent command:

Get-Content "$HOME\.mcp-me\.mcp-me.yaml"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Generate profile data locally

After editing .mcp-me.yaml, run the generator:

npx --yes mcp-me@0.6.0 generate
npx --yes mcp-me@0.6.0 validate
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Connect the same server to multiple clients

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
Enter fullscreen mode Exit fullscreen mode

For Windsurf, add an entry to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "me": {
      "command": "npx",
      "args": ["-y", "mcp-me", "serve"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

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"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

VS Code uses a different top-level key. In .vscode/mcp.json, use servers:

{
  "servers": {
    "me": {
      "command": "npx",
      "args": ["-y", "mcp-me", "serve"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

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.

Verify the server boundary

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
Enter fullscreen mode Exit fullscreen mode

Then start the server in a terminal:

npx --yes mcp-me@0.6.0 serve
Enter fullscreen mode Exit fullscreen mode

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.

Why this works

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.

Failure modes and limitations

The client cannot find 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.

Validation fails after editing YAML

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.

A source returns incomplete data

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.

Local does not mean risk-free

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.

FAQ

Do I need to install 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.

Can different clients use different profiles?

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.

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

Takeaway

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.

Top comments (0)