DEV Community: Kacper Zawojski

Payload v4: the MCP plugin exposes your collections to LLMs — and it's opt-out

Kacper Zawojski — Fri, 26 Jun 2026 09:00:10 +0000

@payloadcms/plugin-mcp turns your Payload CMS into an MCP server, exposing your collections as tools for LLMs.

Heads up for v4: after a refactor, every collection is now exposed with full CRUD by default. It's opt-out — you disable individual tools rather than enabling them:

mcpPlugin({
  collections: {
    // posts is exposed automatically — no entry needed
    users: { tools: { create: false, update: false, delete: false } }, // find only
  },
})

Custom tools are defined with the defineTool builder, taking input via zod v4:

tools: {
  getPostScores: defineTool({
    description: 'Score recent posts',
    input: z.object({ since: z.string() }),
  }).handler(async ({ input, req }) => ({ content: [/* ... */] })),
}

⚠️ The thing to actually do after upgrading: collections you never listed are suddenly reachable through MCP. Review them and disable anything sensitive — an exposed users collection with delete is not a great default to inherit by accident.

Payload v4: stricter cron — sloppyRanges is gone

Kacper Zawojski — Wed, 24 Jun 2026 09:00:11 +0000

Watch out for this one when upgrading to Payload v4: cron parsing got stricter.

After the Croner bump to v10, the sloppyRanges escape hatch is gone. Stepping in a cron expression now has to be syntactically correct, or you get a TypeError at registration time — instead of it being silently ignored:

- cron: '/10 * * * *'      // missing prefix — throws
+ cron: '*/10 * * * *'

- cron: '5/15 * * * *'     // numeric prefix — throws
+ cron: '5-59/15 * * * *'  // explicit range

This applies everywhere you write a schedule: jobs.autoRun[].cron, schedule.cron, and the --cron flag on the binary. The good news is the failure is loud — a malformed expression that used to quietly never fire now throws on startup, so you find out immediately.

Just another app builder for no-code

Kacper Zawojski — Mon, 22 Jun 2026 14:59:59 +0000

We're launching an app I'm building with my cousin @Jędrzej Zawojski

The app is built primarily for no-code, low-code developers and designers. If you keep hearing that your app will eventually fall apart, or that there will come a moment when you won't be able to keep developing it - our app is the answer to that problem.

A set of skills that helps maintain code to the right standard
Maintaining skills and memory
Built-in git - version history and the ability to create new branches, meaning different variations of your app, all stored locally on your machine
A GUI for managing your app - no more burning tokens on restarting, starting, stopping, or committing. Burn tokens on actual development, not on the repetitive stuff developers do from the terminal

We also have a set of starters ready for you. Right now mainly built in Payload, because of my specialization - but many more are coming soon. A starter is a developer-prepared package with a base app, a set of skills, memory, and environment setup, done the way I would set it up myself.

Additional features help you maintain and manage your repository properly - the way a developer would.

Zero vendor lock-in. Everything works with Claude Code, Codex, and even local models. I'm testing the app on Ollama myself and it works.

The official release is coming soon, but if you're interested, message me on LinkedIn to get early access.

TELLMEICANT #JAAB #PAYLOAD

Payload v4: every block gets its own TypeScript interface (hashed on collision)

Kacper Zawojski — Mon, 22 Jun 2026 09:00:07 +0000

A nice quality-of-life change in Payload v4's type generation.

Previously, a block only got its own TypeScript interface if you set interfaceName. In v4 the name is derived automatically from the slug (PascalCased), and when two different blocks would collide on a name, the second one gets a stable suffix from a content hash — so types never silently overwrite each other:

// slug 'content-block'  -> interface ContentBlock
// a colliding block of a different shape -> Hero_3F2A1B0C  (deterministic hash)

The key word is deterministic: the hash is derived from the block's shape, so regenerating payload-types.ts doesn't churn your diffs. No more "why did half my types get renamed" after a codegen run.

Payload depth: how many relationship levels expand — at runtime, not in schema

Kacper Zawojski — Sat, 20 Jun 2026 09:00:09 +0000

depth controls how many levels of relationships Payload expands — and it's a runtime decision, not something baked into your schema.

The same document can come back "flat" or with its relationships populated, driven by a single query parameter:

// depth: 0 -> author is just an ID
{ id: '1', title: 'Hi', author: '64a...' }

// depth: 1 -> author is a full object
{ id: '1', title: 'Hi', author: { id: '64a...', name: 'Ada' } }

await payload.findByID({ collection: 'posts', id, depth: 2 })

And when you want to limit which fields get populated as a document is expanded from another document, reach for defaultPopulate on the collection — so you're not dragging entire heavy documents along for the ride.

Tune depth per query and you control your payload size without touching the data model.

Payload v4: jobs always run at depth 0, with no collection hooks

Kacper Zawojski — Thu, 18 Jun 2026 09:00:25 +0000

A v4 migration gotcha for anyone using Payload's job queue.

jobs.depth and jobs.runHooks were removed. Tasks now signal their result by throwing — not via a state field, which is gone:

// v3 (no longer works)
const myTask: TaskHandler<'MyTask'> = async ({ input }) => {
  if (!input.id) return { state: 'failed', errorMessage: 'Missing id' }
  return { state: 'succeeded', output: { ok: true } }
}

// v4
const myTask: TaskHandler<'MyTask'> = async ({ input }) => {
  if (!input.id) throw new Error('Missing id')  // throw = fail + retry
  return { output: { ok: true } }
}

Jobs always run at depth: 0 now, which means they operate on raw relationship IDs and skip collection hooks. It's faster and far more predictable — no surprise side effects from a hook firing deep inside a background task.

Payload Local API: zero HTTP, but full access control when you want it

Kacper Zawojski — Tue, 16 Jun 2026 09:00:26 +0000

payload.find() hits the database directly, in the same process — no HTTP, no fetch. By default it also bypasses access control, on the assumption that server-side code trusts itself.

That assumption is exactly where holes appear. In server functions and endpoints that run on behalf of a user, you have to consciously turn enforcement on:

// DANGEROUS — full access, ignores access control
const docs = await payload.find({ collection: 'posts' })

// SAFE — respects access control for the given user
const docs = await payload.find({
  collection: 'posts',
  overrideAccess: false,
  user,
})

The trap is the default: overrideAccess is true unless you say otherwise. Any Local API call that returns data to an end user should pass overrideAccess: false and the user.

Payload field hooks run per-field, not per-document

Kacper Zawojski — Sun, 14 Jun 2026 09:00:22 +0000

In most CMSs, hooks live on the whole document. In Payload, a hook lives on a specific field and receives that field's context — siblingData, value, operation:

{
  name: 'slug',
  type: 'text',
  hooks: {
    beforeChange: [
      ({ value, siblingData, operation }) => {
        if (operation === 'create' && !value) {
          return slugify(siblingData.title) // compute the slug from a sibling field
        }
        return value
      },
    ],
  },
}

Combine that with virtual: true and you get purely computed fields: the hook produces the value on afterRead, and nothing ever lands in the database.

It's a small shift in mental model, but it makes logic local to the data it touches instead of scattered across one giant document-level hook.

Payload virtual path fields: relationship data with zero extra columns

Kacper Zawojski — Fri, 12 Jun 2026 09:00:33 +0000

Any field in Payload can be marked virtual. The best version is virtual as a path — it automatically resolves the value from a relationship, with nothing written to the database:

{
  name: 'authorName',
  type: 'text',
  virtual: 'author.name', // walks through the `author` relationship down to `name`
}

And when the path crosses a hasMany relationship, you get an array back:

{
  name: 'categoryTitles',
  type: 'text',
  hasMany: true,
  virtual: 'categories.title', // => ['Tech', 'News', 'Updates']
}

The field shows up in your API responses and in your generated types — but it never takes up a column. Perfect for flattening relationship data without denormalizing your schema.

What would you ask the Framer team if you had the chance?

Kacper Zawojski — Wed, 10 Jun 2026 12:59:59 +0000

What would you ask the Framer team if you had the chance? 👇
Drop your questions in the comments - I'll take them with me and ask on your behalf.

Here's why: on June 16, Framer is dropping its biggest release in years - a fundamentally new way to work in the tool. I'll be watching the launch live at a small, invite-only Watch Party here in Warsaw, then jumping into a hackathon to build with it that same night.

The catch? It's a tiny room (~20 builders), so most of the community can't be there in person - but your questions can. Whatever you're curious about - the new features, the workflow shift, what it means for how we build - send it my way, and I'll bring the answers back here for everyone.

Big things ahead for Framer. Let's explore them together. 💛

PS: And no, I don't only do Payload. Sometimes. 😏

Payload v4: forceSelect is now a select() function — and it's a subtle trap

Kacper Zawojski — Wed, 10 Jun 2026 09:00:25 +0000

In Payload v3, forceSelect was a static object that deep-merged with the caller's select. In v4 it became a function — and that function replaces the caller's select instead of adding to it:

export const Posts: CollectionConfig = {
  slug: 'posts',
  // Careful: you must spread the caller's select yourself, or you'll overwrite it!
  select: ({ operation, req, select }) =>
    select ? { ...select, title: true } : undefined,
  fields: [/* ... */],
}

Returning undefined means "leave the caller's select untouched." You also get operation and req, so you can hand back a different select for the REST API than for the admin panel.

One important detail: there's no document data here — select runs before read.

Payload access control isn't a boolean — it's a query constraint

Kacper Zawojski — Mon, 08 Jun 2026 09:00:34 +0000

This is, in my opinion, Payload's most underrated feature.

An access function can return true/false — or it can return a Where object that Payload stitches into every query at the database level. That's row-level security, for free:

export const canReadPage: Access<Page> = ({ req: { user } }) => {
  if (user) return true

  // A guest only sees public documents — the filter goes to the DB, not to JS
  return {
    isPublic: { equals: true },
  }
}

You don't fetch everything and then filter in memory — this Where becomes part of the WHERE clause in SQL (or $match in Mongo). And it works identically for read, update, and delete.

Once it clicks that access control is a constraint, not a gate, a whole class of "filter the user's own records" problems just disappears.