Restore Sanitized MCP Configurations Without Committing Secrets

AI assistants are useful only when their tools are configured consistently. That consistency becomes risky when a client configuration contains an API key, a browser profile, cookies, or a copied storage state file.

The practical problem is not just "where do I put the MCP server?" It is how to share a reproducible setup without turning a public repository into a credential container.

This tutorial uses paladini/agent-skills to restore sanitized MCP client examples. You will clone the repository, inspect its placeholders, copy one configuration locally, and run the repository's deterministic checks. The same workflow applies to other public configuration examples.

What the repository provides

The repository collects reusable Agent Skills and sanitized configurations for DEV.to, Medium, and LinkedIn workflows. Its README says the configuration examples contain placeholders rather than real credentials, and its publishing guardrails keep the final public action supervised.

The useful design decision is the separation between a shareable shape and a local secret. A repository can document the command, arguments, environment-variable name, and publication boundary. It should not contain the value of DEV_TO_API_KEY, a password, a cookie, an MFA code, or a browser storage state.

This is also consistent with how MCP stdio transport works: the client launches the server as a subprocess and communicates over standard input and output. The client therefore needs a local command and local environment, but those values do not need to be committed to Git. See the MCP transport specification for the transport behavior.

Prerequisites

You need:

• Git;
• Python 3.11 or newer for the bundled validation scripts;
• an MCP-compatible client if you want to connect a server after validation;
• a local directory outside the repository for real secrets and persistent browser profiles.

The checkout used for this tutorial was the repository's main branch at commit f54fb0256aaf0d527f52d140a1c9996ea6925d26, dated 2026-07-21. The repository declares the MIT license in LICENSE. There is no package installation step for the configuration collection itself.

Clone and inspect before copying

Start with a disposable checkout:

git clone https://github.com/paladini/agent-skills.git
Set-Location agent-skills
git log -1 --format="%H %cs"
Get-ChildItem -Recurse mcp-configs

The important files for a DEV.to setup are:

mcp-configs/
  devto/
    .env.example
    client.json.example
    codex.toml.example
  publishing-guardrails.md

Read the example before replacing anything. The current TOML example contains a deliberately invalid executable path and a placeholder secret:

[mcp_servers.devto]
command = "C:\\PATH\\TO\\uv.exe"
args = ["--directory", "C:\\PATH\\TO\\devto-mcp", "run", "server.py"]

[mcp_servers.devto.env]
DEV_TO_API_KEY = "<local>"

This is a template, not a configuration you can run unchanged. Replace the paths in your local client configuration only. Keep the committed example unchanged so another person can understand which values are required.

Restore a local configuration safely

On Windows, copy the example to the local Codex configuration file, then edit the local copy. The repository's README recommends merging the table into %USERPROFILE%\.codex\config.toml.

$repo = (Resolve-Path .).Path
$config = Join-Path $env:USERPROFILE ".codex\config.toml"
Copy-Item "$repo\mcp-configs\devto\codex.toml.example" "$config.devto-example"
notepad "$config.devto-example"

Use an absolute path to the MCP server checkout and the uv.exe executable on your own machine. Put the real key in the client-managed environment or secret store. Do not paste it into the repository file, the example file, a shell history entry, or a tutorial.

If your client accepts JSON instead of TOML, the repository also provides client.json.example with the same structure. The two formats are alternatives. Do not register both unless you intentionally want two server entries.

After editing the real local configuration, verify that the file is outside the Git repository and that the placeholder is not being used accidentally:

$config = Join-Path $env:USERPROFILE ".codex\config.toml"
Resolve-Path $config
Select-String -Path $config -Pattern "mcp_servers|DEV_TO_API_KEY|REPLACE_WITH_LOCAL_SECRET"
git -C $repo status --short

The last command should show no change caused by the local secret configuration. The Resolve-Path result should point to your user configuration directory, not the cloned repository.

Validate the public examples

The repository includes a validator for the committed MCP examples. It checks that the expected JSON and TOML examples exist, parses them, checks the mcpServers and mcp_servers structures, and scans for likely credentials.

python scripts\validate_mcp_configs.py

Expected result:

OK: sanitized MCP configurations are valid

The repository also includes three unit tests for the DEV.to article validator. Run them from the checkout:

python -m unittest discover -s skills\devto-publish-expert\scripts -p "test_*.py"

The observed result for the current checkout was three passing tests. These checks do not prove that an external MCP server is reachable, that an account is authenticated, or that a platform's UI will remain unchanged. They prove a narrower and useful property: the examples are structurally valid and do not contain values matching the repository's credential patterns.

Browser profiles need a different boundary

The Medium and LinkedIn examples use Playwright MCP rather than an API key in the repository. Their local configuration points to a persistent browser profile outside the Git checkout. That profile can contain cookies and authenticated sessions, so it must be treated as private data.

The official Playwright MCP documentation describes persistent, isolated, and extension-based browser modes. It also warns that Playwright MCP is not itself a security boundary. The repository therefore recommends one profile per platform, manual login and MFA, headed browser sessions for publishing workflows, and no committed cookies or storage state.

If you connect to an existing browser, pay special attention to scope. The official Playwright browser connection guide explains that extension mode can reuse logged-in sessions, cookies, and installed extensions. That convenience is exactly why the profile and connection should remain local and supervised.

Failure modes to expect

The client cannot start the server

Check the executable and server directory in the local configuration. A placeholder path from the public example is expected to fail. Also check that the server writes protocol messages to stdout and diagnostics to stderr, as the repository README requires for the DEV.to server.

The server starts but authentication fails

Confirm the environment variable name and the local secret source. Do not solve this by adding the key to codex.toml, client.json, .env.example, or a Git-tracked file. Rotate a key if it was ever committed or pasted into a shared log.

A browser session opens the wrong account

Stop the workflow and inspect the local profile choice. Do not export cookies or storage state to debug it. Use a separate profile per platform and log in manually. A fresh isolated session is safer for testing, but it will not retain the existing login.

The validation script reports a possible credential

Treat the warning as a real review item. Inspect the matching file, remove the value from Git history if necessary, rotate the exposed credential, and rerun the validator. A green result is not a substitute for reviewing the diff.

Security boundaries

Sanitized examples reduce accidental disclosure; they do not make every MCP server safe. An MCP server may be able to read files, call network services, control a browser, or publish externally. Review the server source, pin versions deliberately, use least-privilege credentials, and test read-only operations before write operations.

For publishing workflows, the repository's guardrails say to research and validate first, save a draft when possible, show the final destination and content, and stop before the final public action. Approval to open an editor or save a draft is not the same as approval to publish.

FAQ

Can I commit a real path?

Prefer a placeholder path in a public example. Absolute paths can disclose usernames, private directory layouts, or mounted volumes. Keep machine-specific paths in the local client configuration.

Can I use .env.example for the real key?

No. It is a variable-name reference. Put the actual value in a local secret manager or client environment that is excluded from Git.

Does the validator test the remote platform?

No. It validates the repository's local JSON, TOML, and credential patterns. Account access and platform behavior require a separate, supervised smoke test.

Why keep both JSON and TOML examples?

Different MCP clients accept different configuration formats. Keeping equivalent examples makes the transport shape portable while leaving paths and secrets local.

Takeaway

A reusable MCP setup should share intent and structure, not authentication state. Clone the public Agent Skills repository, inspect its placeholders, copy an example into a user-level configuration, keep profiles and keys outside Git, and run the deterministic validators before connecting a client.

What is the smallest read-only smoke test you require before allowing an MCP server to perform a write or publish action?

AI assistance disclosure: This tutorial was researched and drafted with AI assistance. Repository contents, the current example configuration, validation scripts, and cited primary documentation were checked before publication.