Programmatic Read & Write

What an AI agent can read and write in m18t over MCP today: content, artifacts, PD entities, and events, with brand scoping, search-before-create, and no

What you'll learn

  • What an AI agent can actually read and write in m18t over MCP today.
  • The discipline the surface enforces: brand scoping, search-before-create, no delete.
  • Where the surface stops, so you don't plan around tools that don't exist.

The concept

Once you've connected an MCP client, your agent has a typed set of tools that map to your m18t records. They come in four shapes, and the naming is consistent across every entity:

  • list_* — find records, with a query argument to search. Returns metadata only (titles, slugs, ids, status), not full bodies.
  • read_* — fetch one record's full body by id (the artifact's document, the content's body, an email template's HTML, a feed item's raw data).
  • create_* — make a new record.
  • update_* — change an existing one, including wiring relations via *_ids[] arrays.

That list/read split is on purpose: bodies are heavy, so listing stays cheap and the agent only pulls a full body when it needs one. This is the same agent-first design philosophy — a small, predictable surface an agent can hold onto.

What's in scope today

The surface covers the core operational entities. Read and write both work for:

  • Content — list, read, create, update across all your content types (blog posts, news posts, web pages, and the rest). An agent can draft a piece and set its status.
  • Artifacts — the rich-text docs you attach to specs and notes. List, read, create, update.
  • Product-development entities — the full PD spec: solutions, features, models, attributes, controllers, policies, roles, lifecycles, views, layouts, components. Each has list/read/create/update, and relations wire through *_ids[]. There's also a schema overview the agent can read before it starts.
  • Events — the analytics event registry: list, read, create, update, including the junctions that tie an event to the controller that emits it.
  • Emails — list emails and read a template's HTML. Creating emails from the agent is on the near roadmap rather than live, so treat the email surface as read-leaning today.

Read-only helpers round it out: list_brands (start here to pick a brand), list_assets, and list_feed_items / read_feed_item for the news pipeline.

The discipline the surface enforces

The MCP server ships rules the agent reads on connect. Three matter most:

  1. Brand scoping is explicit. Every brand-scoped tool takes a brand. The agent should call list_brands first and pass the right one on each call. If your workspace has exactly one brand, tools default to it; otherwise, no guessing. This is how m18t keeps an agency's thirty client brands from bleeding into each other.

  2. Search before create. Before any create_*, the agent is told to run the matching list_* with a query to check for an existing record, and to prefer update_* over making a duplicate. Duplicate data is treated as a correctness failure, not a tolerated outcome.

  3. No delete, by design. There is no delete tool in the surface today. To phase out a record, the agent sets its status to deprecate where that applies, or it escalates to you. The destructive operations are deliberately absent, which is what keeps the blast radius small enough to hand an agent a live connection.

Where the surface stops

Be honest about the edges so you don't build a workflow on a tool that isn't there:

  • No deletion, no bulk operations. One record at a time; nothing erased.
  • No asset upload. You can list assets, but uploading a file isn't exposed over MCP — that still happens in the Assets Manager.
  • Email creation is roadmap-adjacent. Reading email templates works; creating them from the agent is not the live path yet.
  • Relations only where exposed. Junctions wire through documented *_ids[] arrays. The agent shouldn't invent junction-wiring beyond those — if a relation isn't exposed, that's a gap to raise, not to work around.

When the agent hits a missing tool, the right move is to surface it to you, not to improvise a workaround that bypasses the surface. The toolset is intentionally minimal at this beta phase; it grows deliberately.

FAQ

Can an agent delete content or PD entities? No. There is no delete tool. The agent phases a record out by setting its status to deprecate (where that applies) or by escalating to you. Nothing is erased over MCP.

Will the agent create duplicates? The server instructs it to search first — run list_* with a query, and update an existing match rather than creating a new one. It's not a hard lock, but the discipline is built into the instructions the agent reads on connect.

Can an agent upload an image or generate one? It can list existing assets, but upload isn't exposed over MCP, and image generation lives in the Graphics Generator, not the agent surface. Asset upload happens in the Assets Manager.

Why does list_* not return the full text? Bodies are heavy. list_* returns metadata so searching stays cheap; call the matching read_* with an id to pull a full body, template, or document.

Can the agent work across two brands at once? One connection covers the whole workspace, and the agent moves between brands by passing a different brand per call. It should call list_brands first and operate on the brand you name.

What's next

Was this article helpful?