Confirm the Pi MCP adapter does not log or cache your tokens
You will test whether the pi-mcp-adapter writes your credentials to logs or caches using a throwaway token before trusting it with real keys. This reduces risk of credentials leaking into files you might not review.
- Confirm official install sourceMatch the package to the project instructions
- Load secrets from envNo hardcoded keys in config or repo
- Run test with dummy tokenUse a key you can revoke
- Search logs and cachesLook for the exact test string
- Verify destination hostsToken should reach only the intended MCP server
Why it matters
The pi-mcp-adapter bridges the Pi coding agent to MCP servers, so it sits on the path where your Pi API keys and MCP server credentials travel. The project's own risk notes flag credential exposure and say to verify that the adapter does not log or cache sensitive tokens. Start from the pi-mcp-adapter on GitHub (opens external site) listing, and treat it as a starting point rather than proof.
Steps
- Install using the setup command shown on the project listing. The listing shows
npx -y pi-mcp-adapter. Before installing, check the project's official instructions for the package so you confirm you are getting the same package they describe.
npx -y pi-mcp-adapter
-
Keep every credential out of config files and the repo. Store Pi API keys and MCP server tokens as environment variables, not hardcoded values. Check how the adapter reads its settings and confirm the secret values come from the environment.
-
Run a test session with a throwaway token. Use a dummy credential that you can revoke right away. Make a few tool calls through the adapter, including at least one that fails, then search the output for that exact string.
-
Check where logs go. Look at the console output and any log files the adapter or Pi writes during the test session. Search those files for the dummy token. Do the same for Pi session history if it is saved to disk.
-
Check for caches. Look in the adapter's working directory, the Pi config folder, and your OS cache directories for files created during the test. Search those files for the dummy token. Note whether the adapter keeps responses or tool results on disk between runs.
-
Watch the traffic. Confirm the token only goes to the MCP server host you intended. Outbound proxy logs or firewall logs can show which hosts receive the credential header.
-
Record the result and repeat after upgrades. Save what you checked and the adapter version. Rerun the same test whenever you update the package.
Common mistakes
- Assuming a README claim is enough. Test with a dummy token and search the files yourself.
- Testing only the happy path. Include errors and timeouts, since error output can include request details.
- Forgetting shell history and debug flags. Verbose or debug modes can print more than normal output.
- Reusing a production key for the test. Use a short-lived key that you can rotate immediately.
Notes on scope
This check covers only the adapter's logging and caching behavior in your setup. It does not show how the upstream Pi agent or the MCP servers store data. Rotate any token that appears in a log or cache file, and keep the package pinned to a version you have tested.
Checklist
0 of 7 done