Integrations

MCP server

Every Sedgemark workspace exposes a Model Context Protocol endpoint. Point an AI agent at it and it can read your schema, write and publish content, and manage forms, all inside its own tool loop, limited to exactly the grants you gave its key.

What this is for

MCP is an open protocol for giving an AI agent tools it can call. Sedgemark implements it so an agent you already work in (Claude Code, Cursor, or anything else that speaks MCP) can operate on your content directly, rather than you pasting API documentation into a prompt and hoping it guesses the shape of your data correctly.

It is also the only way to write content over the API. /api/v1 is read-only; content creation, updates, publishing and deletion live here.

MCP /api/mcp

A valid API key as a bearer token. Streamable HTTP.

Connecting

The transport is Streamable HTTP: one endpoint, no local process to run and nothing to install. Server-sent events are not used.

From the Claude Code CLI:

bash

claude mcp add sedgemark --transport http \
  https://acme.sedgemark.app/api/mcp \
  --header "Authorization: Bearer $SEDGEMARK_API_KEY"

Or, in a client that takes a JSON configuration file. Note that this form puts the key in a file; keep it out of version control, or use whatever environment-variable interpolation your client supports:

json

{
  "mcpServers": {
    "sedgemark": {
      "type": "http",
      "url": "https://acme.sedgemark.app/api/mcp",
      "headers": {
        "Authorization": "Bearer pk_your_key_here"
      }
    }
  }
}

Mint the key under Users & API Keys in the dashboard, checking the grants for what you actually want the agent to be able to do. Without a valid key:

http

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer

{ "error": "Unauthorized: provide a valid API key as a Bearer token" }

The endpoint exists only on a workspace subdomain. Pointing a client at the apex domain returns a 404.

What an agent gets on connection

Before its first tool call, the server hands the agent a short briefing naming your collections and the grants its key holds, so it does not have to discover either by trial and error. Alongside that:

describe_api returns the live /api/v1 contract as structured data: base URL, auth format, pagination shape, the media URL pattern, the rich-text allowlist and the form field contract.
get_client returns the generated TypeScript client for your workspace, without a second authenticated HTTP request.
A sedgemark://guide resource carries the long-form integration guide: framework recipes, the footgun checklist, rich-text rendering.

Between them, an agent should never need to guess at an endpoint or probe for one. If yours is doing that, point it at describe_api first.

Permission gating

Which tools an agent may call is decided entirely by the grants on its key. Every tool is gated, reads included. There is no tool a key reaches merely by being valid. A key carries any combination of grants, so one key can cover an agent that needs several capabilities.

Grant	Unlocks
collections:read	list_collections, get_collection, describe_api, get_client
collections:write	Creating, altering and deleting collections and their fields, including update_field.
entries:read	list_items and get_item, which return drafts as well as published rows.
entries:write	create_item, update_item, set_status, delete_item.
forms:read	list_forms, get_form: the field definitions, not what was submitted.
forms:write	Creating, configuring and deleting forms and their fields, including update_form_field.
submissions:read	list_submissions and get_submission. Never implied by forms:read; this is PII.
users:read	list_user_fields, only when the workspace has the Identity beta enabled. See below.

An agent that needs to both define collections and write entries takes one key holding both grants. Two implications save you checkboxes: any entries grant implies collections:read, and any submissions grant implies forms:read. Neither ever confers a write. Full model: Authentication → Permissions.

An entries:read key can read your drafts here

list_items and get_item return draft and published entries alike: an agent has to be able to see the draft it just created in order to check it before publishing. That is a genuine difference from /api/v1, which never returns drafts to anyone.

So a key granted entries:read gives more access over MCP than the same key gives over HTTP. Say so when you hand one to someone.

Tool inventory

Twenty-eight tools in four families. The form tools are only registered when forms are enabled for the workspace; the one account tool is only registered when the workspace has the Identity beta turned on.

Collections & schema

Tool	Requires
list_collections	collections:read
get_collection	collections:read
describe_api	collections:read
get_client	collections:read
create_collection	collections:write
add_fields	collections:write
update_collection	collections:write
update_field	collections:write: rename, reorder, or change requiredness in place
update_enum_values	collections:write, plus confirmation when removing values
remove_field	collections:write + confirmation
delete_collection	collections:write + typing the slug back

Content entries

Tool	Requires
list_items	entries:read: returns drafts as well as published entries
get_item	entries:read: same
create_item	entries:write
update_item	entries:write
set_status	entries:write: publish or unpublish
delete_item	entries:write + confirmation

Forms

Tool	Requires
list_forms	forms:read
get_form	forms:read
list_submissions	submissions:read
get_submission	submissions:read
create_form	forms:write
add_form_fields	forms:write
update_form	forms:write
update_form_field	forms:write: rename, reorder, or change requiredness in place
remove_form_field	forms:write + confirmation
delete_form	forms:write + typing the slug back

Accounts

One tool, registered only on a workspace with the Identity beta enabled, unlike the form tools, which are on by default.

Tool	Requires
list_user_fields	users:read

Definitions only, never a row

list_user_fields returns the workspace’s custom account field definitions: slug, name, type, required, whether it is collectible at signup, and an enum’s allowed values. It never returns an account, a count, or any aggregate over accounts. There is no other MCP surface for end-user accounts at all; they remain readable only from the dashboard.

Destructive tools ask twice

Anything that drops data takes an explicit confirmation argument, so an agent cannot do it as a side effect of a plausible-looking plan. Removing a field or deleting an entry needs confirm: true; deleting a whole collection or form needs the slug typed back and matched exactly; a whole-table blast radius earns the stronger guard.

Two conventions worth knowing

Slugs are interchangeable. Every tool that addresses a collection accepts it as either collection or slug; form tools accept slug or form_slug. Pass one. Passing both with different values is an error rather than a silent pick.
Publishing manages its own timestamp. Setting an entry’s status to published stamps _published_at; returning it to draft clears it. Do not set both by hand.

Verify a write by re-reading it

The responses from create_item and update_item omit many-to-many relation keys, because those are written in a second statement after the row itself. get_item, list_items and /api/v1 all report them correctly. An agent checking its own work should re-read rather than trust the write response.

Handing a key to an agent

Grant the narrowest set that works. An agent drafting blog posts needs entries:write, not collections:write: with only the former it can fill your collections and cannot alter or drop one. Checking a box is cheap; unchecking it after an agent has used it is not.
Withhold submissions:read by default. Submissions are usually personal data belonging to people who never agreed to it being read by a model. forms:read lets an agent work on a form’s structure without ever seeing what was submitted through it.
Use a separate key per agent, so revoking one does not disturb the others.
Remember drafts come with entries:read. There is no grant that reads published content over MCP but not drafts.