Keep MCP Evidence

keep-mcp evidence

Prove the action through the actual MCP client and verify its effect independently in Google Keep. Test output belongs in code blocks, never screenshot substitutes. Prefer a CLI-based MCP client when available. Use the current agent's connected MCP tools if they target the verified build, otherwise use a bounded CLI invocation such as Codex exec or Cursor CLI. Honour the user's client choice and record its name/version. A desktop client is a fallback, not a requirement.

Save the exact prompt and actual MCP call/result events as text. CLI transcripts belong in code blocks; client screenshots are optional. Google Keep screenshots still provide the independent visual evidence. Read cli-runs.md when using a CLI client.

Preflight

• Read the diff and choose concrete visible outcomes. Read scenarios.md for the checklist scenarios from PR #19.
• Verify the client's keep-mcp launch command resolves to the checkout/build under test. Record commit, dirty status, interpreter, SDK version and transport without logging environment values. Restart/reconnect the server after changes. A checked out commit alone does not establish which server an already-running client uses.
• If multiple Keep servers are configured, target the exact server under test and inspect every invocation. Do not silently fall back to another server.
• Open Google Keep in an isolated authenticated browser session when available. Confirm it is the same account as the configured server, without publishing the account identifier. Prefer a dedicated test account. If login is needed, leave the page open and ask the user to sign in. Continue independent preparation while waiting. Never request tokens/passwords in chat or copy browser credentials.
• Use UNSAFE_MODE=false. Operate only on fixtures created for this run, with names keep-mcp-evidence-<UTC timestamp>-<random suffix>-<scenario>. Record returned note IDs immediately. Keep a local manifest of IDs and cleanup status. Never delete unrelated notes or the shared keep-mcp label.

Run and capture

1. Write down the exact prompt, expected MCP operation/arguments, expected visible state and timeout. Use a fresh fixture per scenario. Fixture setup also goes through the client when feasible; identify any separate setup method explicitly.
2. Plan only the Keep checkpoints needed to prove the visible outcome. Use the client transcript for intermediate checks. Batch independent final fixture checks into one scoped Keep view when readable. Capture a before state when needed to demonstrate a change; do not take a screenshot after every tool call.
3. Submit the saved prompt through the real MCP client. With a CLI, retain its structured tool-call events and results. With a desktop client, expand the tool details and capture them. An assistant's success message alone is insufficient.
4. Match actual arguments and returned note ID against the scenario. If the model corrects invalid input, substitutes another tool, or refuses to call, mark that negative case not exercised. One clarified retry is reasonable; don't keep creating notes or replace the invocation with a Python call to manufacture proof.
5. In Keep, find/open the exact fixture and wait for synchronization, refreshing when necessary. Assert the visible title, item text and checked state. Bound the wait, for example to 60 seconds. A timeout is inconclusive, not proof of absence. For failed updates, also make a benign supported update and reload: this helps expose unintended cached mutations that could be synced on a later request. Keep the rejected update and follow-up sync in the same server process; a fresh CLI invocation can discard the very cached mutation this scenario tests.
6. Capture the resulting Keep state. Capture before-build evidence on separate fixtures when practical; don't confuse a starting state with reproduction on an old build. Never stage expected UI using browser edits or mock pages.
7. Inspect every image for legibility and private content. Frame the fixture and client exchange tightly, excluding unrelated notes, conversations, account menus and credentials. Cropping/redaction may hide private content, but must not alter the behavior shown. Never publish browser storage, tokens or raw private logs.
8. Clean up only recorded fixture IDs, preferably by moving them to recoverable trash through the client. Verify cleanup and record any leftover IDs. If a call times out, search for the unique title before retrying creation or cleanup.

Use browser/computer tools for Keep checkpoints and screenshot capture, not to drive a client that has a usable CLI. Stop inspecting once a checkpoint is clear. Use screenshots from supported browser/native capture tools. Load the relevant browser skill when available. No generated screenshots, reconstructed conversations, or screenshots of pytest/terminal output in place of real use.

Delivery and reproducibility

Use evidence-template.md. Keep captures and raw observations in an ignored local testing-evidence/<PR>/<run-id>/ directory. The manifest records client/build, fixture IDs, prompts, actual calls, timestamps, assertions, screenshot filenames, coverage gaps and cleanup. Never include secrets. Publish only reviewed screenshots and selected non-sensitive facts to the requested PR when authorized. Attach screenshots directly to the PR and quote decisive CLI output in collapsible code blocks in its description or a comment. Keep run-specific screenshots, transcripts and reports out of version control unless the user explicitly requests otherwise. Do not create a repository evidence folder as an upload workaround. If attachments are blocked, preserve the files locally and report the blocker. Offer the files for manual attachment instead of escalating into desktop automation. Reusable recipes belong in the skill; individual run results belong in the PR.

If login, client access or build provenance is unavailable, report the exact blocker, leave the PR draft, and preserve the recipe for resumption. Do not mark the screenshot requirement satisfied or substitute automated tests. A skill passing static validation is not evidence that the live workflow has passed.