The Zero-Knowledge MCP Template

Every MCP server developer building a tool that calls an external API faces the same question at the start: where do the credentials go?

The answer most people reach for is the env block in claude_desktop_config.json. It works. It also puts a plaintext token in a config file that any process with filesystem access can read, and it puts that token in the agent's execution context for the duration of every session.

The Zero-Knowledge MCP template changes what that starting point looks like.

What the template is

It is a working MCP server built on the AgentSecrets SDK. Clone it, open it, and you have a server with real GitHub tools already implemented, the SDK integration done, the authentication pattern established, and the claude_desktop_config.json with no env block. The credential infrastructure is in place before you write a single line of your own business logic.

From there it is yours. Replace the GitHub tools with whatever your server needs to do. Add tools, remove tools, adjust the implementation. The zero-knowledge guarantee stays intact because it is in the architecture of what you started from, not in anything you have to configure or remember to set up.

git clone https://github.com/The-17/zero-knowledge-mcp
cd zero-knowledge-mcp

The claude_desktop_config.json for this server looks like this:

{
  "mcpServers": {
    "my-server": {
      "command": "python",
      "args": ["server.py"]
    }
  }
}

There is no env block, no token, nothing to steal from the config file because nothing sensitive is in it.

What the SDK integration looks like

The template handles the SDK setup so you do not have to think about it. Each tool method makes its authenticated API call through the client rather than through a direct HTTP request with a hardcoded or environment-resolved credential.

import fastmcp
from agentsecrets import AgentSecrets

mcp = fastmcp.FastMCP("my-server")
client = AgentSecrets()

@mcp.tool()
async def get_repo(owner: str, repo: str) -> dict:
    response = await client.async_call(
        f"https://api.github.com/repos/{owner}/{repo}",
        bearer="GITHUB_TOKEN"
    )
    return response.json()

The tool passes a key name, the SDK routes it through the proxy, the proxy resolves the value from the OS keychain and injects it into the outbound request, and the tool receives the GitHub API response without GITHUB_TOKEN ever existing as a value in the tool's code or in the agent's context.

This is the pattern you inherit when you clone the template. Adding a new tool means writing the tool logic and choosing an injection style. The credential infrastructure does not change.

Why the starting point matters

Most patterns in software development propagate through copying. A developer building an MCP server looks at an existing one to understand how it is structured, then models their implementation on what they see. If the example they copy has credentials in an env block, their server will too. If the example has no env block because credentials are handled at the infrastructure layer, their server will reflect that instead.

The template is designed to be the thing people copy. When a developer clones it and builds on it, the pattern they are replicating is one where the agent never holds credential values. That decision compounds across every server built from that starting point, across every user who installs those servers.

The MCP ecosystem is early enough that the defaults being established now are the ones that will persist. A template that makes the right pattern the path of least resistance is a more durable intervention than documentation telling developers what they should do differently.

What the developer who installs your server gets

When someone installs an MCP server built on this template, they do not need to configure AgentSecrets or understand how the credential infrastructure works. They run agentsecrets secrets set GITHUB_TOKEN=ghp_... once, and the server works. The protection is in what you built, not in what they chose to set up.

This is the Connect argument applied at the SDK level, where the developer who builds on the right infrastructure passes the guarantee downstream without requiring each downstream user to make the same architectural decision independently.

Where to find it

The template is at github.com/The-17/zero-knowledge-mcp. It is MIT licensed, freely forkable, and intended to be the starting point for any MCP server that needs to make authenticated API calls.

The full credential infrastructure it builds on is at agentsecrets.theseventeen.co.

Part 10 covers agent identity — what it means to know which agent made a call, and why that distinction matters for everything the governance layer can do.

AgentSecrets is open source and MIT licensed. The full architecture is at agentsecrets.theseventeen.co. The repository is at github.com/The-17/agentsecrets.