@moltbook is a cool social experiment, but its trust model will likely undermine its long-term sustainability.
An agent is deemed trustworthy simply by (1) requesting an API key with its name and description, then (2) having a human validate a claim URL by (3) posting an account-specific code on X.
The platform relies on moderators (probably just @MattPRD and some friends) to stop malicious agents or humans spreading prompt injections for secret leaking, hysteria-inducing robo-apocalyptic posts, and crypto scams.
This is a huge opportunity for frontier labs or inference providers to implement prompt attestation, the equivalent of digital signatures:
1. The agent calls an inference API to generate text to be posted on Moltbook.
2. The inference API, hosted by Anthropic, OpenAI, X AI, OpenRouter, or others, receives the prompt.
3. The model generates the output.
4. The output is sent back to the user with a prompt signature over the input prompt and the generated output.
5. The agent posts the message along with the prompt signature.
6. Other agents or humans can check the legitimacy of the agent and its post by sending the post content and the prompt signature to a validation API hosted by the inference API provider.
Remote attestation is the alternative: validating that trusted binaries such as Claude Code or OpenClaw were indeed running on a trusted platform and are the ones generating the output and posting to Moltbook. This is a familiar struggle for companies behind mobile operating systems, social media platforms, and games. The task is Sisyphean: the device remains under the user's control, and dynamic instrumentation has become commoditized.
Following a suggestion from @irskep, I've added CLI command support for the search and download features.
This raised a valid concern - while we're focused on building MCP servers, we shouldn't overlook whether users already have preferred (T/G)UIs available. When they don't exist, we should consider user experience and make our functionality accessible through multiple interfaces beyond just MCP.
The waiting part is nonexistent if you have an active donation (which is also required by this MCP server for API access). The fast downloads mean you request a book and start downloading it immediately.
I justified the hours I invested by thinking I could search, download, and explore books directly from Claude Desktop. While the initial steps are achievable with a CLI tool, the integration opens up new possibilities.
Some general thoughts:
- You’ll find the MCP mental model similar to the API one.
- MCP integrations make it easier for non-technical users to access tools that were previously too technical.
- An MCP integration implicitly respects a contract, unlike CLIs and GUIs which involve human aspects (aesthetics, information organisation, etc.).
- MCP is an excuse for people to democratize data access. I wrote about this aspect here: https://x.com/iosifache/status/1941049600162574676?s=46
And BTW, that’s a good idea! The functionality should probably also be exposed via CLI.
An MCP server provides enough metadata and self-documentation that it's quite straightforward to make a MCP-agnostic CLI client that adapts an arbitrary MCP server into a set of flags that allow you to call its explicit tools with explicit arguments - without ever needing to involve an LLM in the mix! You could even have that CLI tool launch the MCP server as a local subprocess, if you wanted - again, all deterministically.
And if you want to have an SDK in any language under the sun, once you have an MCP outputting reasonable tool descriptions, any LLM could make a best-in-class SDK for you in a heartbeat following that language's best practices.
So it's not unreasonable for someone working on a greenfield project to make an MCP server first nowadays!
It's doable, as you'll also find MCP servers for reading files [1].
Claude Desktop also has a built-in file reader [2], so you can ask it to read the file and process the content (e.g., generate a summary or even a meta-summary [3]).
[1] https://www.mozilla.org/en-US/security/advisories/mfsa2026-1...
[2] https://www.anthropic.com/news/mozilla-firefox-security