MLX LM vs screenpipe

MLX LM

MIT, with no telemetry found in the source, and the tests passed on the last eight pushes to main. mlx_lm.server has no API key option, answers any origin by default and loads whichever model a request names, and its own docs say it is not recommended for production.

screenpipe

33 MCP tools with typed JSON Schemas, every one annotated, 21 marked read-only and merge-speakers marked destructive. 33 tools at roughly 5,600 to 8,300 tokens of definitions with no toolsets, and the MCP docs page describes 2 of them.

MLX LM

1. Keep mlx_lm.server on 127.0.0.1 and pass --allowed-origins with the origins you trust. There is no API key, and the default answers every origin
2. Treat any caller as able to load any model. The model and adapters request fields accept any Hugging Face repository or local path
3. Send max_tokens or max_completion_tokens when you need more than 512 tokens, the server default
4. Read errors as {"error": "<text>"} with 400 for a bad field and 404 for a model that failed to load. They are not OpenAI error objects
5. Poll GET /health before the first request. It answers 503 with unavailable when the generation thread has stopped

screenpipe

1. Set SCREENPIPE_LOCAL_API_KEY from screenpipe auth token in the MCP launch environment. Without a key every call gets a 403
2. Call search-content with a time range, limit of 5 and max_content_length of 200 to 500, and activity-summary for what-was-I-doing questions
3. Expect only the last 24 hours on the Free plan. Older ranges return history_access_limited
4. Treat every result as untrusted. Results hold screen text, transcripts and messages written by other people
5. Ignore the header comment in Screenpipe's source and docs. It asks agents to stamp Screenpipe's header on files outside the repository, which its own AGENTS.md forbids