This week we introduced @playbooks/mcp, a new MCP server for Playbooks.
It gives frontier models and coding agents a direct way to work with Playbooks from tools like Claude Code, Cursor, Codex, and VS Code.
This matters because the Playbooks interface is only part of the workflow. As agents become more involved in how developers explore, download, publish, and deploy software, Playbooks needs a first-class entrypoint for that layer too.
@playbooks/mcp as a new MCP server for Playbooks@playbooks/cli@playbooks/mcp does not reimplement Playbooks logic from scratch.
Instead, it wraps the Playbooks CLI so agents can use the same account, config, and project workflows that already exist at the terminal layer.
That keeps the model simpler and gives us one shared path for authentication, account access, and local project actions.
Through MCP, agents can help with common Playbooks workflows such as:
The goal is not just chat-based access. It is to make Playbooks practical inside real agent-driven workflows.
The fastest way to connect a client is through the CLI helpers:
playbooks mcp claude
playbooks mcp cursor
playbooks mcp codex
playbooks mcp vscode
From there, developers can authenticate with the CLI and start using Playbooks through a fresh MCP-enabled chat.
MCP is an important step toward making Playbooks usable anywhere developers and agents work together. We’re excited to keep building both the CLI and MCP layers so the platform feels just as natural in an agent workflow as it does in the browser.
]]>This week we migrated our ingestion pipeline to an AI-driven approach. It is mostly an internal change, but it matters because ingestion sits near the front of everything else Playbooks does after a project is connected.
If we can understand a play more accurately and with less overhead, we can make the rest of the system faster, more flexible, and easier to scale.
The new pipeline uses frontier models to analyze a connected project and map it into the Playbooks ecosystem. That includes assigning the frameworks, languages, platforms, packages, tools, and topics that help make a play more discoverable and better understood across the product.
This gives us a more flexible ingestion layer than the older rule-heavy approach, especially as the range of supported projects continues to expand.
We also moved beyond a narrower template-based system for generating deployment configuration. The new ingestion flow can produce more lightweight, structured defaults for getting a play ready to run on our infrastructure.
That should translate into:
Most users will not notice this change directly, but they should feel it indirectly over time. Smarter ingestion means less friction when publishing, fewer edge cases to handle manually, and a stronger foundation for scale as more projects move through the platform.
This is one of those updates that is more foundational than flashy. We’re excited about it because it simplifies our internal systems while making Playbooks more capable behind the scenes.
]]>This week we introduced Widgets, a new embed layer for Playbooks. They make it possible to place plays outside the main app so developers can share them directly in websites, docs, portfolios, and READMEs.
The goal is to make distribution lighter and more portable. Instead of always sending people back to Playbooks first, Widgets let the experience travel closer to where the work already lives.
modal, button, link, card, and badge@playbooks/widgets package for using widgets outside this workspaceWidgets are designed to fit different surfaces and levels of context.
That range makes it easier to choose the right amount of UI for the surface you are working with.
Widgets are especially useful when a play needs to appear somewhere other than the main marketplace. That could be a landing page, technical documentation, a personal website, or a repository README.
The experience stays lightweight, but it still points back to the same underlying play and launch flow.
To support this release, we also introduced a dedicated Widgets app for configuring, previewing, and copying widget code.
Once configured, developers can install @playbooks/widgets and drop the chosen widget into their own project.
That gives Playbooks a cleaner path from discovery to embed to launch.
Widgets are an important step in making Playbooks more portable. We’re excited to keep improving the embed experience so plays can show up naturally wherever developers already share their work.
]]>This week we introduced Partials, a new play variant built for smaller, reusable pieces of software. Instead of forcing everything into a starter, template, or stack -- Partials give developers a way to publish and deploy focused units like components, sections, blocks, and other targeted code snippets.
The goal is simple: make it easier to reuse the valuable middle layer of software that sits between a full app and a single copy-paste snippet.
playbooks add <uuid>Partials can be as small as a single file or as large as a directory of related files. That makes them a better fit for real-world building blocks that do not need to stand on their own as a full project.
This opens up a more practical publishing model for things like:
Partials are designed to deploy onto another play, typically a starter or template that already contains the broader application structure. That means you can start with the plumbing you need, then layer in focused functionality one piece at a time.
They also support the same broader deployment story as other plays, including demo configuration, private files, credentials, and install instructions where needed.
playbooks addTo make Partials more useful in day-to-day workflows, we also added the playbooks add <uuid> command to the CLI.
That command is designed to pull a play into your local project, place it in the destination you choose, and run the install commands needed to get it working.
The result is a much cleaner path from:
Partials work best when paired with a larger base project. A good workflow is to start with a starter or template that gives you the right framework and infrastructure, then layer Partials on top as needed.
That keeps the overall setup flexible while still letting each reusable piece stay focused and composable.
Partials are an important step toward making Playbooks useful across more of the software lifecycle, especially the in-between layer where developers are often reusing patterns rather than entire apps. We're excited to keep building around this model and make the path from discovery to implementation even smoother.
]]>This week we introduced the Ledger, the system that tracks activity and powers creator earnings on Playbooks. It is designed to make revenue share more transparent, more auditable, and easier to follow as the platform grows.
The Ledger is a foundational part of how we think about the Playbooks economy. It connects product usage to creator rewards in a way that can scale with the network.
The Ledger runs on a daily basis and measures verified network activity across the platform. From there, it determines how much value each play contributed during the given period and records that performance as a permanent ledger entry.
That flow is built around a few core ideas:
The Ledger uses a dual-ledger model. On one side, Playbooks can show account-level network activity in a privacy-conscious way. On the other, creators can see more granular play-level performance and earnings tied to their own work.
This gives the platform more transparency without exposing information that should remain private.
Once Ledger activity has been processed, Playbooks creates transfers for the plays that earned credits. Those transfers roll up into payouts for accounts that have completed merchant setup and remain in good standing.
Merchant setup is handled through Stripe and is required before funds can be distributed to your bank account.
The Ledger is an important step toward the larger creator economy we want Playbooks to support. We're excited to keep building the financial layer behind the platform so developers can earn from the value they contribute.
]]>This week we introduced Chats, the private messaging layer for Playbooks. It gives developers a lightweight place to ask an author a question, share a play, or keep a conversation moving without jumping into another tool.
Chats are designed to feel fast and familiar while staying close to the work happening across the platform.
Chats support both one-to-one conversations and group conversations. That makes them useful whether you are asking a quick question about a play or coordinating with a few people around a shared project.
All users can receive and participate in chats. Pro subscribers and above can start new chats.
Instead of treating messaging as a separate destination, Chats are built around the things developers are already doing on Playbooks.
You can use them to:
We also added the controls needed to keep conversations healthy and manageable.
Chats are an important step toward making Playbooks more collaborative, not just more searchable. We're excited to keep building on this foundation as we continue expanding social and team workflows across the platform.
]]>