
### Overview

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.

### What's New

- Added `@playbooks/mcp` as a new MCP server for Playbooks
- Added support for clients like Claude Code, Cursor, Codex, and VS Code
- Added CLI helpers for installing MCP client configuration
- Reused the same Playbooks session and config model as `@playbooks/cli`
- Exposed common Playbooks workflows to agents through MCP tools

### Built on the 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.

### What Agents Can Do

Through MCP, agents can help with common Playbooks workflows such as:

- checking authentication and session state
- exploring marketplace and account resources
- downloading, adding, and cloning plays into local projects
- syncing, publishing, and deploying plays

The goal is not just chat-based access.
It is to make Playbooks practical inside real agent-driven workflows.

### Getting Started

The fastest way to connect a client is through the CLI helpers:

```sh filename="Terminal" copy
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.

### That's all for now

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 introduced `@playbooks/mcp`, a new MCP server for Playbooks. It lets frontier models and coding agents connect to the same Playbooks workflows already available through the CLI. 

Eric Hubbell

W14: Introducing MCP


### Overview

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.

### What's New

- Replaced the older synchronous mapping flow with an AI-driven ingestion pipeline
- Added parallel processing for more of the ingestion workload
- Improved how plays are mapped into the Playbooks taxonomy
- Improved how deployment defaults are generated for incoming projects
- Reduced manual and template-heavy internal processes

### Better Project Understanding

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.

### Better Deployment Defaults

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:

- fewer manual steps on our side
- better default accuracy
- a cleaner path from connected source to runnable demo

### Why It Matters

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.

### That's all for now

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 migrated our ingestion pipeline to an AI-driven approach. The change is mostly behind the scenes, but it gives use a faster, smarter, and more scalable way to integrate projects into Playbooks. 

W12: Data Ingestion


### Overview

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.

### What's New

- Added a dedicated Widgets app for configuring and previewing embeds
- Added five widget types: `modal`, `button`, `link`, `card`, and `badge`
- Added copy-paste installation and embed code for each variant
- Added support for embedding plays across websites, docs, and READMEs
- Added the `@playbooks/widgets` package for using widgets outside this workspace

### Five Widget Types

Widgets are designed to fit different surfaces and levels of context.

- **Modal** for launching a Playbooks experience inline
- **Button** for a straightforward call to action
- **Link** for lightweight text-based placement
- **Card** for a richer preview of a play
- **Badge** for compact display in docs and repositories

That range makes it easier to choose the right amount of UI for the surface you are working with.

### Built for Distribution

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.

### Configurator and Package

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.

### That's all for now

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 Widgets, a new way to embed Playbooks outside the core app. Widgets make it easier to place plays across websites, documentation, and READMEs with lightweight, copy-pasteable components. 

W10: Introducing Widgets


### Overview

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.

### What's New

- Added Partials as a new way to package reusable code
- Added support for deploying a Partial on top of a larger template project
- Added support for file-level and directory-level Partials
- Added CLI support through `playbooks add <uuid>`
- Added a cleaner path from discovery to install for smaller building blocks

### A Smaller Unit of Reuse

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:

- UI components
- page sections
- feature blocks
- focused patterns that belong inside a larger codebase

### Designed to Layer on Top

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.

### CLI Support with `playbooks add`

To 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:

- finding a Partial
- adding it to a project
- installing what it needs
- continuing work locally

### Best Fit

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.

### That's all for now

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 Partials, a new way to package and deploy smaller units of code on Playbooks. Partials make it easier to share components, sections, and other reusable pieces without wrapping everything in a full starter or stack. 

W8: Introducing Partials


### Overview

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.

### What's New

- Added the Ledger as the system of record for creator earnings
- Added daily processing with a rolling verification lag
- Added account-level and play-level performance tracking
- Added transfer and payout pipelines for verified merchant accounts
- Added a 60/40 revenue split in favor of creators

### How It Works

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:

- only verified activity should influence earnings
- the record should be immutable once written
- creators should be able to understand where their revenue is coming from

### Public and Private Visibility

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.

### Transfers and Payouts

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.

### Important Details

- the Ledger runs daily with a rolling 30-day verification lag
- only accounts and teams in good standing are eligible for processing
- transfers and payouts require an active merchant account
- payout activity is designed to stay automated, while still giving creators control from settings

### That's all for now

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 the Ledger, the economic engine behind Playbooks. It gives creators a transparent way to track performance, measure verified activity, and receive transfers and payouts over time. 

W6: Introducing the Ledger


### Overview

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.

### What's New

- Added private messaging to Playbooks
- Added direct messages and group chats
- Added attachments for plays, frameworks, user profiles, etc
- Added sub-threads for smaller conversations inside a larger chat
- Added controls for muting, editing, blocking, and reporting

### Direct and Group Chats

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.

### Built Around the Work

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:

- ask an author a question before getting started
- share discoveries with another developer
- forward attachments such as plays, frameworks, and user profiles
- carry out richer conversations with text, files, and code snippets
- branch into sub-threads when one part of the conversation needs its own lane

### Privacy and Controls

We also added the controls needed to keep conversations healthy and manageable.

- mute chats you do not want to follow closely
- edit chats and messages as needed
- block or report another user at any time

### That's all for now

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.


 This week we introduced private messaging to Playbooks. Chats make it easier to ask questions, share discoveries, and collaborate directly with other developers without leaving the platform. 

Blog

W14: Introducing MCP

W12: Data Ingestion

W10: Introducing Widgets

W8: Introducing Partials

W6: Introducing the Ledger

W3: Introducing Chats

Company

Explore

Resources

Other