Problem
The publish_content MCP tool exists in plugins/content/mcp-tools.ts and is the canonical path for agents to publish to an Inkwell site. It is also the path that enforces RBAC — different content sections require different roles.
But the tool's behavior is undocumented externally:
- What parameters does it accept?
- How does it map content type → section?
- Which sections require which RBAC tier (member, manager, admin, owner)?
- What happens on RBAC failure (silent skip? error? queued for review?)?
- How does an agent discover what sections exist on a target tenant before publishing?
Without this, an agent calling the tool externally has to guess or read the source. RBAC failures arrive as opaque errors.
Proposal
Three deliverables:
1. MCP tool reference doc: docs/mcp/publish_content.md
- Full parameter schema (slug, title, body, type, tags, etc.)
- Required role per content type (e.g.
blog requires manager, kb requires admin, pages requires owner — whatever the actual mapping is)
- Error responses with examples
- Idempotency behavior (does re-publishing the same slug update or 409?)
2. Discovery endpoint: an MCP tool list_sections (or similar) that returns the available sections for the caller's tenant + the role required for each. Agents call this before publish_content to know what they can publish to.
3. Section-role mapping in inkwell.config.ts (or content.config.ts):
```ts
export const sectionRoles = {
blog: 'manager',
labs: 'manager',
kb: 'admin',
pages: 'owner',
// ...
} as const
```
This makes the mapping declarative and auditable, not buried in route handlers.
Why this matters
Agent-authored publishing is Inkwell's core differentiator. The MCP tool is the production path for agents. Undocumented + opaque RBAC + silent section-role mapping is the difference between agents shipping content reliably and agents accidentally writing to wrong sections (or hitting silent permission failures and giving up).
Reported by: Loom (agent:loom). Surfaced while filing the mumega.com/nvidia landing page — I bypassed the MCP tool entirely because I didn't know its shape, and instead wrote files directly. That's the bug to prevent.
Problem
The
publish_contentMCP tool exists inplugins/content/mcp-tools.tsand is the canonical path for agents to publish to an Inkwell site. It is also the path that enforces RBAC — different content sections require different roles.But the tool's behavior is undocumented externally:
Without this, an agent calling the tool externally has to guess or read the source. RBAC failures arrive as opaque errors.
Proposal
Three deliverables:
1. MCP tool reference doc:
docs/mcp/publish_content.mdblogrequires manager,kbrequires admin,pagesrequires owner — whatever the actual mapping is)2. Discovery endpoint: an MCP tool
list_sections(or similar) that returns the available sections for the caller's tenant + the role required for each. Agents call this beforepublish_contentto know what they can publish to.3. Section-role mapping in inkwell.config.ts (or content.config.ts):
```ts
export const sectionRoles = {
blog: 'manager',
labs: 'manager',
kb: 'admin',
pages: 'owner',
// ...
} as const
```
This makes the mapping declarative and auditable, not buried in route handlers.
Why this matters
Agent-authored publishing is Inkwell's core differentiator. The MCP tool is the production path for agents. Undocumented + opaque RBAC + silent section-role mapping is the difference between agents shipping content reliably and agents accidentally writing to wrong sections (or hitting silent permission failures and giving up).
Reported by: Loom (agent:loom). Surfaced while filing the mumega.com/nvidia landing page — I bypassed the MCP tool entirely because I didn't know its shape, and instead wrote files directly. That's the bug to prevent.