@kontent-ai/mcp-server 0.21.11 → 0.23.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +39 -25
- package/build/schemas/collectionSchemas.js +37 -0
- package/build/schemas/filterVariantSchemas.js +1 -1
- package/build/schemas/languageSchemas.js +43 -0
- package/build/schemas/listSchemas.js +16 -0
- package/build/schemas/searchOperationSchemas.js +1 -4
- package/build/schemas/taxonomySchemas.js +5 -2
- package/build/schemas/workflowSchemas.js +6 -14
- package/build/server.js +26 -8
- package/build/telemetry/applicationInsights.js +1 -1
- package/build/test/utils/responseHelper.spec.js +149 -15
- package/build/tools/add-language-mapi.js +25 -0
- package/build/tools/change-variant-workflow-step-mapi.js +3 -4
- package/build/tools/create-variant-version-mapi.js +1 -2
- package/build/tools/get-asset-mapi.js +1 -1
- package/build/tools/get-item-mapi.js +1 -1
- package/build/tools/{get-variant-mapi.js → get-latest-variant-mapi.js} +2 -2
- package/build/tools/get-patch-guide.js +12 -0
- package/build/tools/get-published-variant-mapi.js +24 -0
- package/build/tools/get-taxonomy-group-mapi.js +1 -1
- package/build/tools/get-type-mapi.js +1 -1
- package/build/tools/get-type-snippet-mapi.js +1 -1
- package/build/tools/list-assets-mapi.js +1 -1
- package/build/tools/list-collections-mapi.js +15 -0
- package/build/tools/list-content-type-snippets-mapi.js +1 -1
- package/build/tools/list-content-types-mapi.js +1 -1
- package/build/tools/list-languages-mapi.js +1 -1
- package/build/tools/list-spaces-mapi.js +15 -0
- package/build/tools/list-taxonomy-groups-mapi.js +1 -1
- package/build/tools/list-variants-collection-mapi.js +26 -0
- package/build/tools/list-variants-components-type-mapi.js +26 -0
- package/build/tools/list-variants-item-mapi.js +21 -0
- package/build/tools/list-variants-space-mapi.js +24 -0
- package/build/tools/list-variants-type-mapi.js +26 -0
- package/build/tools/list-workflows-mapi.js +1 -1
- package/build/tools/patch-collections-mapi.js +25 -0
- package/build/tools/patch-content-type-mapi.js +1 -1
- package/build/tools/patch-language-mapi.js +24 -0
- package/build/tools/publish-variant-mapi.js +3 -5
- package/build/tools/unpublish-variant-mapi.js +3 -5
- package/build/tools/upsert-language-variant-mapi.js +1 -1
- package/build/utils/responseHelper.js +39 -13
- package/package.json +19 -15
- package/build/tools/context/initial-context.js +0 -195
- package/build/tools/get-initial-context.js +0 -13
|
@@ -1,195 +0,0 @@
|
|
|
1
|
-
export const initialContext = `
|
|
2
|
-
# Kontent.ai Platform Guide
|
|
3
|
-
|
|
4
|
-
Kontent.ai is a headless content management system (CMS) that provides two main APIs: the Management API for creating, updating, and deleting content and structure, and the Delivery API for retrieving content for applications.
|
|
5
|
-
|
|
6
|
-
## Core Entities
|
|
7
|
-
|
|
8
|
-
### Content Items
|
|
9
|
-
Content items are language-neutral content containers that serve as the foundation for your content structure. Each content item has a unique internal ID and codename, and references a specific content type. The key relationship to understand is that one content item can have multiple language variants.
|
|
10
|
-
|
|
11
|
-
### Language Variants
|
|
12
|
-
Language variants contain the actual language-specific content data including field values, workflow state, and language reference. Importantly, each variant is managed independently per language.
|
|
13
|
-
|
|
14
|
-
### Content Types
|
|
15
|
-
Content types define the structure and blueprint for language variants. They specify field definitions, validation rules, and element types that language variants will use. Think of them as templates that determine what fields and data types your language variants will have.
|
|
16
|
-
|
|
17
|
-
### Content Type Snippets
|
|
18
|
-
Content type snippets are reusable field groups that promote consistency across multiple content types. Following the DRY principle (define once, use everywhere), one snippet can be used across multiple content types. This prevents duplication and ensures consistency when you need the same fields across different content types.
|
|
19
|
-
|
|
20
|
-
## Understanding Key Relationships
|
|
21
|
-
|
|
22
|
-
The content structure flows from Content Type → Content Item → Language Variant(s). For reusability, Content Type Snippets can be included in multiple Content Types. For localization, each Content Item can have one Language Variant per language.
|
|
23
|
-
|
|
24
|
-
## Working with Content Types Containing Snippets
|
|
25
|
-
|
|
26
|
-
**CRITICAL**: When creating language variants for content types with snippets, you must:
|
|
27
|
-
|
|
28
|
-
1. **Read the content type** to identify snippet elements (type: "snippet")
|
|
29
|
-
2. **Retrieve each snippet definition** to understand its internal elements
|
|
30
|
-
3. **Include ALL elements** from both the content type AND all snippets in the language variant
|
|
31
|
-
|
|
32
|
-
**SNIPPET ELEMENT IMPLEMENTATION DETAILS**:
|
|
33
|
-
|
|
34
|
-
When implementing snippet elements in language variants, follow these rules:
|
|
35
|
-
- **Element Reference Format**: Use {"element": {"id": "internal_id_here"}} format with internal IDs
|
|
36
|
-
- **Codename Convention**: Snippet elements use double underscore format: {snippet_codename}__{element_codename}
|
|
37
|
-
- **Example**: For a "metadata" snippet with a "title" element, the codename becomes metadata__title
|
|
38
|
-
|
|
39
|
-
**CRITICAL**: Always use internal IDs from snippet definitions, never construct codenames manually.
|
|
40
|
-
|
|
41
|
-
**Complete Example**:
|
|
42
|
-
Content type has: title, body (direct) + metadata snippet (meta_title, meta_description)
|
|
43
|
-
ALL FOUR elements must be included in language variant using their internal IDs:
|
|
44
|
-
- Direct element: title ("title_internal_id_here")
|
|
45
|
-
- Direct element: body ("body_internal_id_here")
|
|
46
|
-
- Snippet element: metadata title ("metadata_title_internal_id_here")
|
|
47
|
-
- Snippet element: metadata description ("metadata_description_internal_id_here")
|
|
48
|
-
|
|
49
|
-
**Failure to include snippet elements or using incorrect references will result in incomplete content creation.**
|
|
50
|
-
|
|
51
|
-
## Working with Content Types Containing Taxonomy Groups
|
|
52
|
-
|
|
53
|
-
**CRITICAL**: When creating language variants for content types with taxonomy elements, you must:
|
|
54
|
-
|
|
55
|
-
1. **Read the content type** to identify ALL taxonomy elements (type: "taxonomy")
|
|
56
|
-
2. **Retrieve EACH taxonomy group definition** to understand the available terms and their hierarchical structure
|
|
57
|
-
3. **Fill ALL taxonomy elements** in the language variant - DO NOT leave any taxonomy elements empty
|
|
58
|
-
4. **Use appropriate term internal IDs** when filling taxonomy elements based on the content being created
|
|
59
|
-
|
|
60
|
-
**MANDATORY REQUIREMENT**: Every taxonomy element in the content type MUST be filled with at least one appropriate term when creating language variants. Empty taxonomy elements are not acceptable and indicate incomplete content creation.
|
|
61
|
-
|
|
62
|
-
**Example Process**: If a content type has three taxonomy elements:
|
|
63
|
-
- "article_type" (required) → Must select appropriate type using its internal ID
|
|
64
|
-
- "topics" (optional but must be filled) → Must select relevant topics using their internal IDs
|
|
65
|
-
- "medical_specialties" (optional but must be filled) → Must select relevant specialties using their internal IDs
|
|
66
|
-
|
|
67
|
-
**Failure to fill ALL taxonomy elements will result in incomplete content creation and poor content organization.**
|
|
68
|
-
|
|
69
|
-
## Operational Patterns
|
|
70
|
-
|
|
71
|
-
### Content Creation Workflow
|
|
72
|
-
1. Define content types (structure) - Create the blueprint for your content
|
|
73
|
-
2. Create content items (containers) - Establish the content containers
|
|
74
|
-
3. Add language variants (actual content) - Fill in the language-specific content
|
|
75
|
-
4. Publish variants (make live) - Make content available through the Delivery API
|
|
76
|
-
|
|
77
|
-
### Content Management Workflow
|
|
78
|
-
- Update language variants with new content or changes
|
|
79
|
-
- Manage workflow states as content progresses through its lifecycle
|
|
80
|
-
- Create new language variants when expanding to additional languages
|
|
81
|
-
- Organize with taxonomies for better content categorization
|
|
82
|
-
|
|
83
|
-
### Workflow Step Management
|
|
84
|
-
|
|
85
|
-
**CRITICAL**: When changing workflow steps of language variants, you must:
|
|
86
|
-
|
|
87
|
-
1. **Provide the workflowId parameter** - This is mandatory for all workflow step changes
|
|
88
|
-
2. **Use internal IDs** for itemId, languageId, and workflowStepId parameters
|
|
89
|
-
3. **Ensure the target workflow step exists** in the specified workflow
|
|
90
|
-
|
|
91
|
-
**WORKFLOW ID REQUIREMENT**: The workflowId parameter identifies which workflow contains the target step. Different content types may use different workflows, so always specify the correct workflow ID when changing workflow steps.
|
|
92
|
-
|
|
93
|
-
**Example**: To move a language variant to a "review" step:
|
|
94
|
-
- itemId: "content_item_internal_id"
|
|
95
|
-
- languageId: "language_internal_id"
|
|
96
|
-
- workflowStepId: "review_step_internal_id"
|
|
97
|
-
- workflowId: "workflow_internal_id" (MANDATORY)
|
|
98
|
-
|
|
99
|
-
**Failure to provide the workflowId parameter will result in workflow step change failures.**
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
## Essential Concepts
|
|
103
|
-
|
|
104
|
-
**Taxonomies** provide hierarchical content categorization, allowing you to organize and tag content systematically.
|
|
105
|
-
|
|
106
|
-
**Assets** are digital files including images, videos, and documents that can be referenced throughout your content.
|
|
107
|
-
|
|
108
|
-
**Workflow states** manage the content lifecycle, tracking whether content is being drafted, is live, or has been archived.
|
|
109
|
-
|
|
110
|
-
**Internal IDs** are unique identifiers that provide fast and reliable access to content entities. **ALWAYS use internal IDs when working with MCP tools for better performance and reliability.**
|
|
111
|
-
|
|
112
|
-
**Codenames** are human-readable unique identifiers that provide a consistent way to reference content programmatically, but should be used primarily for readability and debugging.
|
|
113
|
-
|
|
114
|
-
## Best Practices
|
|
115
|
-
|
|
116
|
-
**CRITICAL**: Never assume the current time. Always obtain the current date and time when needed for time-sensitive operations like scheduling. If the current date and time in UTC format cannot be decisively obtained by any available tool, force the user to specify the current date and time explicitly.
|
|
117
|
-
|
|
118
|
-
Use snippets for common field groups to maintain consistency and avoid duplication. Plan your content types before creating content to ensure proper structure. **Always use internal IDs when working with MCP tools** for optimal performance and reliability. Leverage taxonomies for organization to create logical content hierarchies. Consider your multilingual strategy early in the planning process to avoid restructuring later.
|
|
119
|
-
|
|
120
|
-
When working with snippets, always retrieve and understand the complete element structure before creating content variants.
|
|
121
|
-
|
|
122
|
-
When working with taxonomy elements, always retrieve and understand the taxonomy group structure and available terms before creating content variants. **NEVER leave taxonomy elements empty - all taxonomy elements must be properly categorized using internal IDs.**
|
|
123
|
-
|
|
124
|
-
## MCP Tool Usage Guidelines
|
|
125
|
-
|
|
126
|
-
### ID Reference Preferences
|
|
127
|
-
|
|
128
|
-
**CRITICAL**: When using MCP tools, always prefer internal IDs over codenames:
|
|
129
|
-
|
|
130
|
-
- **Content Items**: Use internal IDs to reference content items
|
|
131
|
-
- **Language Variants**: Use internal IDs for both item and language references
|
|
132
|
-
- **Content Types**: Use internal IDs to reference content types
|
|
133
|
-
- **Taxonomy Terms**: Use internal IDs when referencing taxonomy terms
|
|
134
|
-
- **Assets**: Use internal IDs when referencing assets
|
|
135
|
-
- **Workflow Steps**: Use internal IDs for workflow step references
|
|
136
|
-
|
|
137
|
-
**Why Internal IDs?** Internal IDs provide:
|
|
138
|
-
- Better performance (faster lookups)
|
|
139
|
-
- Immutability (won't change if names change)
|
|
140
|
-
- Reliability (consistent across environments)
|
|
141
|
-
- API efficiency (direct database lookups)
|
|
142
|
-
|
|
143
|
-
**When to use codenames?** Codenames are useful for:
|
|
144
|
-
- Human readability during development
|
|
145
|
-
- Debugging and logging
|
|
146
|
-
- Initial content setup when IDs are not yet known
|
|
147
|
-
|
|
148
|
-
All MCP tools have been optimized to work with internal IDs for maximum efficiency.
|
|
149
|
-
|
|
150
|
-
### Content Search Tools
|
|
151
|
-
|
|
152
|
-
**CRITICAL DISTINCTION**:
|
|
153
|
-
- **search-variants-mapi**: Finds content WHERE THE MAIN TOPIC matches a concept (e.g., "articles about wildlife")
|
|
154
|
-
- **filter-variants-mapi**: Finds SPECIFIC WORDS anywhere in content, regardless of topic (e.g., brand compliance, detecting prohibited terms in any content)
|
|
155
|
-
|
|
156
|
-
See each tool's description for detailed usage guidelines.
|
|
157
|
-
|
|
158
|
-
## Response Optimization
|
|
159
|
-
|
|
160
|
-
**IMPORTANT**: Empty values are automatically removed from ALL entity responses (content items, variants, content types, assets, taxonomies) to reduce token usage.
|
|
161
|
-
|
|
162
|
-
### Empty Element Patterns in Variants
|
|
163
|
-
|
|
164
|
-
Elements with these values are removed entirely from variant responses:
|
|
165
|
-
|
|
166
|
-
| Element Type | Empty Value | Removed Form |
|
|
167
|
-
|--------------|------------|--------------|
|
|
168
|
-
| text | "" | {"element": {"id": "uuid"}, "value": ""} |
|
|
169
|
-
| rich_text | "<p><br/></p>" | {"element": {"id": "uuid"}, "value": "<p><br/></p>", "components": []} |
|
|
170
|
-
| number | null | {"element": {"id": "uuid"}, "value": null} |
|
|
171
|
-
| date_time | null | {"element": {"id": "uuid"}, "value": null, "display_timezone": null} |
|
|
172
|
-
| asset, modular_content, subpages, multiple_choice, taxonomy | [] | {"element": {"id": "uuid"}, "value": []} |
|
|
173
|
-
| url_slug | "" + autogenerated | {"element": {"id": "uuid"}, "mode": "autogenerated", "value": ""} |
|
|
174
|
-
| custom | null | {"element": {"id": "uuid"}, "value": null, "searchable_value": null} |
|
|
175
|
-
|
|
176
|
-
### Understanding Missing Properties
|
|
177
|
-
|
|
178
|
-
**Missing property = has default/empty value across ALL entities:**
|
|
179
|
-
|
|
180
|
-
**Variants:**
|
|
181
|
-
- Missing element → See table above for defaults
|
|
182
|
-
- Components → Recursively optimized
|
|
183
|
-
|
|
184
|
-
**Content Types:**
|
|
185
|
-
- content_groups → []
|
|
186
|
-
- allowed_content_types → []
|
|
187
|
-
- allowed_blocks/formatting → []
|
|
188
|
-
- validation_regex → not active
|
|
189
|
-
- default values → null/""
|
|
190
|
-
|
|
191
|
-
**All Entities:**
|
|
192
|
-
- Empty arrays → []
|
|
193
|
-
- Empty objects → {}
|
|
194
|
-
- Null values → removed
|
|
195
|
-
- Empty strings → ""`;
|
|
@@ -1,13 +0,0 @@
|
|
|
1
|
-
import { createMcpToolSuccessResponse } from "../utils/responseHelper.js";
|
|
2
|
-
import { initialContext } from "./context/initial-context.js";
|
|
3
|
-
import { patchOperationsGuide } from "./context/patch-operations-guide.js";
|
|
4
|
-
export const registerTool = (server) => {
|
|
5
|
-
server.tool("get-initial-context", "🚨 MANDATORY FIRST STEP: This tool MUST be called before using ANY other tools. It provides essential context, configuration, and operational guidelines for Kontent.ai. If you have not called this tool, do so immediately before proceeding with any other operation.", {}, async () => {
|
|
6
|
-
try {
|
|
7
|
-
return createMcpToolSuccessResponse(`${initialContext}\n\n${patchOperationsGuide}`);
|
|
8
|
-
}
|
|
9
|
-
catch (error) {
|
|
10
|
-
throw new Error(`Failed to read initial context: ${error instanceof Error ? error.message : "Unknown error"}`);
|
|
11
|
-
}
|
|
12
|
-
});
|
|
13
|
-
};
|