MCP logs should tell me what failed and enough info to debug it. If it also gives me my access token that accompanied it, then we're in trouble.
An OAuth failure can cross that line without anyone deliberately logging a token. A URL might carry a secret in its query string. A form body might contain one. Then an error handler copies the request into a message you paste into an issue.
Why does a debugging aid become a credential store? Because the copied error outlives the short session you were trying to fix.
MCP Inspector 2.9.0 gives us an interesting use case of this.
modelcontextprotocol
/
inspector
Visual testing tool for MCP servers
MCP Inspector
A developer tool for inspecting Model Context Protocol (MCP) servers. It ships as a single package, @modelcontextprotocol/inspector, that provides four ways to inspect a server:
- Web — a Vite + React + Mantine single-page app with a Node backend.
- CLI — a scriptable command-line client for automation, CI, and fast agent feedback loops.
- TUI — an interactive terminal UI built with Ink.
-
mcpdo (experimental) — a connection CLI: connect once, then run many commands against the named connection through an implicit local daemon. See
clients/mcpdo.
The first three run through one global mcp-inspector binary; mcpdo is a second binary in the same package:
npx @modelcontextprotocol/inspector # web UI (default)
npx @modelcontextprotocol/inspector --cli # CLI
npx @modelcontextprotocol/inspector --tui # TUI
npx -p @modelcontextprotocol/inspector mcpdo --help # mcpdo
Warning
The Inspector manages secrets — OAuth tokens, OAuth client secrets, and stdio env: values — and stores them…
The release moves acquired OAuth tokens into a secret store and includes fixes for redacting URL query secrets in CLI error envelopes and form secrets in recorded bodies. One fix addresses a form secret whose tail was split by a raw &. Those details tell you where to look when you review your own MCP tooling: storage, error text, and recorded requests don't necessarily handle secrets the same way.
Review the artifact you’re about to share
Before you attach an Inspector log, terminal capture, or tool-call trace to a public issue, read the copy that will leave your machine. Don't rely on a reassuring UI view if you're about to share the underlying file.
Start with URLs. Keep the endpoint, status, and the fact that an OAuth step failed. Remove credentials from query parameters before you paste the URL anywhere. Check error messages too; they may quote the URL rather than showing it as a separate request field.
Next, inspect request and response bodies. Form data deserves a close look, especially when an error records the raw body. Redaction code has to handle imperfect input, as Inspector's raw-& fixes show. A field looking masked in one view isn't proof that every recorded copy is masked.
Then check where tokens live between runs. Inspector 2.9.0 stores acquired OAuth tokens in a secret store, but storage deserves its own review. The release notes document a known issue: OAuth profiles sharing a server can overwrite each other's tokens. If you use MCP_INSPECTOR_OAUTH_STATE_PATH for separate profiles against that server, the notes say to give each profile a distinct secret store using MCP_INSPECTOR_SECRET_STORE=file and a separate MCP_INSPECTOR_SECRET_FILE, or a per-profile MCP_STORAGE_DIR. The default single-profile setup is unaffected.
Finally, treat an exposed credential as exposed. Editing it out of a later issue comment doesn't remove it from an earlier notification, download, or copied trace. Revoke or rotate it through the provider, then replace the shared artifact with a sanitized version.
MCP is one of the open projects under the Agentic AI Foundation. Its tools are meant to be inspected, tested, and discussed in public. You should be able to report the failed OAuth step and the response that led you there without handing the next reader a working credential. Keep the diagnostic detail. Leave out the token.
Top comments (1)
Good checklist. One more surface for anyone running a computer-use MCP server: the tool-call arguments themselves. If the agent logs in with a plain type(text) call, the password sits in the client transcript and in any trace you later attach to an issue, no OAuth involved.
Disclosure: I'm on the Auten team (a computer-use MCP). We hit exactly this and split it into a separate fill_login tool that takes only the saved login's name. The value is typed locally, so it never reaches the model's context or the trace, and it refuses to type on any site other than the one it was first used on. Same idea as your last line: keep the diagnostic detail, leave out the secret.