# Webiny CMS MCP MCP

> Webiny CMS MCP connects your AI agent directly to your headless content system. Draft, publish, and manage content across models and locales using natural conversation. It handles the complex data operations of an enterprise CMS without you having to write GraphQL queries or manually update JSON payloads.

## Overview
- **Category:** developer-tools
- **Price:** Free
- **Tags:** graphql-api, content-modeling, serverless, content-lifecycle, data-structures, open-source

## Description

Managing a modern content stack used to mean jumping between dashboards, drafting JSON in playgrounds, and praying the API call didn't fail halfway through. Now, your agent handles it all. You tell it what needs changing—like updating an article across three languages or publishing a new author profile—and it executes the necessary steps within the Webiny CMS environment.

It’s not just about reading data; this MCP lets you manage the entire content lifecycle, from drafting initial entries to running raw GraphQL mutations for complex operations. Need to audit what field was changed last? You can check entry revisions and global tenant configurations easily. This level of operational visibility is critical. Because all these calls are handled through Vinkius, every action generates a cryptographically signed audit trail, giving you undeniable proof of exactly who did what and when it happened.

## Tools

### create_cms_entry
Drafts a new content piece for a specified model using JSON data.

### delete_cms_entry
Permanently removes a specific, existing content entry revision from the system.

### execute_graphql_query
Runs raw GraphQL queries or mutations against the entire CMS API.

### get_api_introspection
Retrieves a map of all available content types, fields, and models in the CMS.

### get_model_entry_details
Fetches specific metadata or field values for a single, known entry revision ID.

### get_tenant_config
Retrieves high-level global settings and configurations for the entire CMS tenant.

### list_model_entries
Lists all existing content entries for a specific model type, whether they are drafts or live.

### publish_cms_entry
Makes an already drafted entry visible and accessible through the primary API read endpoint.

### update_cms_entry
Changes specific field values on a content entry revision that currently exists.

## Prompt Examples

**Prompt:** 
```
List all entries for the 'BlogPosts' model in en-US.
```

**Response:** 
```
I found 8 entries in 'BlogPosts': 1. 'Introduction to Headless CMS' (ID: post-1), 2. 'Getting Started with Webiny' (ID: post-2), 3. 'GraphQL Best Practices' (ID: post-3), and 5 others. Which one would you like to see details for?
```

**Prompt:** 
```
Create a new 'Author' entry: { 'name': 'John Doe', 'bio': 'Tech Writer' } in en-US.
```

**Response:** 
```
Success! I've created a new draft entry for 'Author' (ID: auth-999) with the provided details. Would you like me to publish it now?
```

**Prompt:** 
```
Publish the entry with ID 'post-123' for model 'Article'.
```

**Response:** 
```
I've successfully published the 'Article' entry (ID: post-123). It is now live and accessible via your Read API. Is there anything else you'd like to update?
```

## Capabilities

### Drafting content entries
Creates new draft versions for any defined content model.

### Publishing live content
Moves a finished draft entry to a published, read-accessible state.

### Updating existing entries
Modifies specific fields on an already existing content entry revision.

### Executing custom data queries
Runs raw GraphQL mutations or reads against the CMS for highly customized operations.

### Listing and discovering models
Retrieves lists of existing content entries or discovers available field types in the system.

### Auditing configurations
Checks global tenant settings, model details, and historical entry revisions for compliance checks.

## Use Cases

### The urgent multi-locale update
A marketing manager needs to change a product description on five different articles across three languages (en-US, es-MX, fr-CA). Instead of logging into the CMS multiple times, they prompt their agent: 'Update article X's key feature description for all locales.' The agent uses `update_cms_entry` and repeats it for each required locale.

### The schema verification roadblock
A developer is building a new module that needs to read content from an obscure model. They first run `get_api_introspection` to discover the exact type name and available fields, then use `execute_graphql_query` to test the data structure before writing any code.

### The retiring content audit
An administrator needs to delete an old, unrecoverable piece of content. They run `get_model_entry_details` first to confirm the ID and revision details, then use `delete_cms_entry` to permanently remove it with a single command.

### The draft-to-live promotion
A content editor finishes an article and needs it live. They tell the agent: 'Publish the latest revision of Article Y.' The agent uses `publish_cms_entry` to move the content into a publicly readable state, making it available for consumption immediately.

## Benefits

- Publishing is simple: Instead of manually finding the entry ID and running a specific publish command, you simply tell your agent to make it live using `publish_cms_entry`. It handles the state change.
- You avoid drafting JSON payloads. To create content, just provide the model name and field data; the `create_cms_entry` tool drafts the whole thing for you.
- Need to know what fields exist? Use `get_api_introspection`. This immediately maps out your entire CMS structure so you never have to guess or check external documentation again.
- `list_model_entries` gives you a clear overview of all content items in a model, letting you quickly locate specific drafts or published versions across different locales.
- The `execute_graphql_query` tool lets developers run complex data reads or writes for niche use cases that simple CRUD operations can't handle. It’s full raw power when needed.
- Audit trails are airtight. Because all these calls flow through Vinkius, you get a cryptographically signed record of every operation—proving exactly what state the content was in before and after.

## How It Works

The bottom line is that you treat content management like a conversation, not a series of API endpoints.

1. First, you provide the MCP your Webiny API domain and access token credentials.
2. Next, you instruct your agent to perform a content operation—for example, 'List all draft posts for Q3' in English.',
3. Finally, the connector runs the necessary sequence of calls (read -> process -> write) and reports the result directly back to your chat interface.

## Frequently Asked Questions

**How do I know what fields are available using `get_api_introspection`?**
It provides a complete, automated map of every content model and field type in your entire CMS instance. This lets you understand the full data structure before you write any query.

**Can I use `execute_graphql_query` to read published or draft content?**
Yes, it handles both. You specify whether you're running a 'read' query for live public data or a 'manage' query for accessing drafts and internal data.

**What is the difference between `list_model_entries` and `get_model_entry_details`?**
`list_model_entries` gives you a broad list of records (e.g., 'I see 12 posts'), while `get_model_entry_details` drills down into one specific record to show its exact field values and metadata.

**Does using `publish_cms_entry` make the content visible immediately?**
Yes, running this tool moves the entry's status from draft to live. It makes the content available via your public read API endpoint right away.

**What happens when I use `create_cms_entry`? Does the content go live immediately?**
No, it creates a new draft entry. The content is saved as an un-published revision first. You must explicitly call another function to publish it and make it available for reading.

**How do I use `update_cms_entry` while ensuring I don't overwrite unrelated fields?**
You provide the entry ID along with a JSON object containing only the specific field updates. This mechanism prevents you from accidentally wiping out existing data on other parts of the record.

**What risks am I taking when running `delete_cms_entry`?**
This action permanently deletes a content entry revision and cannot be undone. Always confirm the exact ID you intend to delete before calling this function, as it's irreversible.

**What is the best way to check the overall health and global settings of my CMS environment? (Using `get_tenant_config`)**
`get_tenant_config` retrieves the high-level, global settings for your entire Webiny tenant. This confirms that your core API access and environmental configurations are set up correctly.