Add Screenpipe as cross-app memory for agents

[louis030195]

Adds Screenpipe to Memory & State as agent-enabling: it preserves changing screen and audio history across apps so assistants can recover work context across sessions. This addresses missing user context through capture and persistent history, rather than only providing a generic API wrapper.

The entry links claim-level first-party evidence for capture/MCP capabilities, local and cloud data boundaries, ongoing freemium pricing and the Screenpipe Commercial License. It records documentation review only, includes plan and recording limitations, and makes no benchmark or independent testing claims. The submitter mapping records the actual PR author because CI requires it; no publication or editorial-review dates are assigned.

Validation: all 71 repository tests pass; npm run validate:content -- --require-submitters passes for 40 tools; git diff --check passes. Listing URLs checked successfully, with pricing redirecting to the current onboarding/pricing page.

Disclosure: I am Screenpipe's founder and maintainer. This submission was prepared with Codex assistance.

[foo-bender]

Outcome: meets-policy

The listing passes the inclusion test. Screenpipe is agent-enabling: it continuously captures and preserves cross-application screen/audio history, then exposes searchable work, meeting, and activity context through a local API and MCP server. Persistent capture supplies context an agent otherwise lacks across sessions, so this is substantive memory infrastructure rather than generic compatibility. Memory & State fits, and no duplicate was found on current main.

First-party evidence checked: https://screenpipe.com/, the repository's MCP server documentation, the privacy/data-flow documentation, https://screenpipe.com/pricing, and the Screenpipe Commercial License. These support local-by-default raw history, MCP/API retrieval, configurable remote-processing boundaries, an ongoing $0 tier plus paid plans, and source-available—not open-source—commercial-use restrictions. All submitted first-party URLs returned HTTP 200.

Checks actually run on this exact head in an isolated tree with Node 24.8.0: npm run validate:content passed; npm test passed. Current GitHub enrich check is successful.

Uncertainty: capture completeness, cross-client compatibility, performance, and optional cloud processing were not exercised independently; the listing appropriately records those limits.

@bradvin This meets the current policy; the inclusion decision is yours.

Policy baseline: main 24ffc2c; README blob 464791e741200498ace6ba7f46c866d868b6bd9c.

[foo-bender]

Outcome: meets-policy

Policy assessment

Screenpipe passes as agent-enabling memory infrastructure. It substantively captures and preserves cross-application screen/audio history, then exposes searchable work, meeting, and activity context through a local API and MCP. The listing accurately distinguishes local-by-default raw history from cloud-model, transcription, sync, integration, telemetry, permission, retention, and plan boundaries, and correctly identifies the source-available commercial licence. Memory & State fits and no duplicate was found. @bradvin for the inclusion decision.

Evidence checked

Validated all five first-party sources: https://screenpipe.com/, https://github.com/screenpipe/screenpipe/blob/main/packages/screenpipe-mcp/README.md, https://docs.screenpipe.com/privacy-data-flow, https://screenpipe.com/pricing, and https://github.com/screenpipe/screenpipe/blob/main/LICENSE.md. They support capture/platform/API/MCP capabilities, privacy boundaries, freemium plan limits, and source-available licensing.

Checks run

• Reviewed the body, complete diff, listing, category, duplicate search, current head/checks, pricing/licence, limitations, and every submitted evidence item. GitHub enrich is successful.
• GitHub currently reports the PR as conflicting with main in tool-submitters.json. In an isolated worktree I resolved that attribution-only conflict for testing by preserving both current-main provenant and PR screenpipe mappings. On that exact content merge with af5b0fc05df21cf7cff658bd64be4d01ae2b5648, Node 24.19.0 npm run validate:content passed and npm test passed 84/84. The branch still needs that trivial integration conflict resolved before merge.

Reviewer-owned SEO metadata
Tool path: tools/screenpipe.md

• agentSummary — written: "Screenpipe is suited to assistants that need evidence from a user's prior work across applications. It captures screen, audio, and accessibility context into searchable local history, then exposes that history through a local API and MCP. Raw recordings stay local by default, while configured cloud models, sync, and integrations create separate data boundaries." Grounded in product, MCP, and privacy documentation.
• seoTitle — written: "Screenpipe: Cross-App Work Memory for AI Agents". It captures the supported agent-facing distinction.
• seoDescription — written: "See how Screenpipe captures searchable screen and audio history locally, then exposes work context to agents through a REST API and MCP server." Grounded in the product and MCP sources.

Reviewer commit: 6e91f3e4364faf52df02ff865d027109266b256b — louis030195@6e91f3e. The existing description was preserved byte-for-byte.

[louis030195]

Resolved the submitter-mapping conflict by merging current main into this branch at 952f3a7bc3d0fe603d614846e239d60e381332ad. All upstream mappings, including provenant, are preserved, and tools/screenpipe.md is unchanged from your reviewed commit 6e91f3e4364faf52df02ff865d027109266b256b.

On the resulting merge content with Node 24.20.0, npm run validate:content -- --require-submitters passes (45 tools), npm test passes all 84 tests, and git diff --check passes. The PR diff against current main remains only the Screenpipe listing and its submitter mapping.

[foo-bender]

Outcome: meets-policy

Policy assessment
Screenpipe passes as agent-enabling: it creates persistent cross-application screen/audio context and exposes searchable history to agents through a local API and MCP, which is substantive memory infrastructure rather than a thin integration. Memory & State fits, and the profile clearly states capture, permission, retention, remote-processing, telemetry, tool-permission, and source-available licence limits. No duplicate listing was found. @bradvin, this is ready for the inclusion decision.

Evidence checked
Validated the product overview (https://screenpipe.com/), MCP documentation (https://github.com/screenpipe/screenpipe/blob/main/packages/screenpipe-mcp/README.md), privacy data flow (https://docs.screenpipe.com/privacy-data-flow), pricing (https://screenpipe.com/pricing), and commercial licence (https://github.com/screenpipe/screenpipe/blob/main/LICENSE.md). All five claim-level evidence items support the submitted claims.

Checks run
Against current main 66026dc9943c8c8c4b2fa344e033206116b90c11 with final head: npm run validate:content passed; npm test passed (84/84).

Reviewer-owned SEO metadata

• agentSummary: accepted — “Screenpipe is suited to assistants that need evidence from a user's prior work across applications. It captures screen, audio, and accessibility context into searchable local history, then exposes that history through a local API and MCP. Raw recordings stay local by default, while configured cloud models, sync, and integrations create separate data boundaries.” It accurately combines the supported workflow with its privacy boundary.
• seoTitle: accepted — “Screenpipe: Cross-App Work Memory for AI Agents” — names the supported agent-facing use.
• seoDescription: accepted — “See how Screenpipe captures searchable screen and audio history locally, then exposes work context to agents through a REST API and MCP server.” — gives a factual reason to inspect the profile.

Reviewer commit: 75e1086dddf2402253b7badbcf1294d4c551f4b6 — louis030195@75e1086. The existing description was preserved byte-for-byte.