BlogPost Model Setup: Learning from Assumptions
When setting up the BlogPost content model in Agility CMS, the AI agent ran into several issues trying to configure it via the MCP Server. The model needed specific field types and relationships that weren't immediately clear from the schema documentation.
BlogPost Model Setup: Learning from Assumptions
Date: January 6, 2026
Phase: Phase 2 - Core Infrastructure
Status: Complete (with manual intervention)
Note: This post is written from Joel's perspective (first person "I" = Joel). The narrative describes what the AI agent attempted and what Joel fixed manually. Technical details sections are clearly marked as written by the AI agent (Cursor - Claude Code).
The Challenge
When setting up the BlogPost content model in Agility CMS, the AI agent (Cursor) ran into several issues trying to configure it via the MCP Server. The model needed specific field types and relationships that weren't immediately clear from the schema documentation, and the agent made several assumptions that didn't match what I actually needed.
What the Agent Tried
The agent attempted to create the BlogPost model with these assumptions:
Assumption 1: Content Field Type
- What the agent tried: Used
Htmlfield type for the blog post content - Why: Assumed rich text content would need HTML formatting
- Reality: I wanted a
Textfield configured as a custom "Markdown" field, matching the pattern I'd already established with my Basic Markdown component model
Assumption 2: Author Field
- What the agent tried: Added a
LinkedContentSharedLinkfield for Author - Why: The development plan mentioned an Author model, and the agent assumed blog posts would need to reference authors
- Reality: Since it's my personal blog with only one author (me), the Author field wasn't needed at all
Assumption 3: Category and Tags as Simple Fields
- What the agent tried: Initially tried to use
Textfield for tags (comma-separated) andDropdownListfor category - Why: Assumed these could be simple field types
- Reality: I wanted Category and Tags to be their own content models with proper linked content relationships
What I Fixed Manually
I manually configured the BlogPost model in Agility CMS with the correct setup:
- Removed Author field - Not needed for a single-author blog
- Created Category and Tag models - Separate content models for proper relationships
- Set up LinkedContent fields correctly:
- Category:
LinkedContentDropdownpointing to Category model - Tags:
LinkedContentSearchListBoxpointing to Tag model - Both configured with proper hidden fields (
categoryID,tagIDs) to store values
- Category:
- Used custom fields - "Slug" and "Content" (Markdown) as custom field types
- Organized with tabs - Used tab fields to organize the form interface
Visual Reference: Agility CMS Configuration
Here's what the final BlogPost model looks like in Agility CMS:
Blog Post Content Model

The model includes all the necessary fields organized into tabs (Main, Media, Content) for a clean editing experience.
Category Field Configuration (Linked Content)

This shows the detailed configuration of the Category linked content field.
Key Learnings
For Future Content Model Creation:
- Check existing patterns first - Look at how similar models are configured
- Custom fields matter - Agility CMS supports custom field types that may not be obvious from the API schema
- LinkedContent requires helper fields - Always create hidden Integer/Text fields to store the actual values
- Field naming can be custom - Capitalized field names are valid and may be intentional
- Question assumptions - Just because a model exists in the plan doesn't mean it's needed
Joel's Thoughts / Reflections
I ended up having to do a bunch of manual work on the Blog Post content model. Not happy with that, but I THINK this is because Cursor just isn't great with MCP calls. I'll have to do future testing to see how Claude Code does with a blank slate like this.
Basically, it got the Linked Content all wrong for Categories and Tags. Eesh.
This is something that we (the Agility team) want the MCP server and our templates to be super helpful with. I think we should build some example prompts for basic use cases. Blog posts, employee bios, products, etc. These are all common use cases we want to handle in future-proof ways.