Understand Contentstack tool definitions
Contentstack publishes tool definitions at public HTTPS endpoints. These endpoints return metadata only. They do not execute API requests and they do not include credentials.
Each endpoint returns a JSON object keyed by tool name.
The available tool definition endpoints are:
https://mcp.contentstack.com/cma/tools
https://mcp.contentstack.com/cma-extended/tools
https://mcp.contentstack.com/cda/tools
https://mcp.contentstack.com/brandkit/tools
https://mcp.contentstack.com/lytics/tools
https://mcp.contentstack.com/personalize/tools
https://mcp.contentstack.com/analytics/tools
https://mcp.contentstack.com/launch/tools
https://mcp.contentstack.com/developerhub/toolsEach group maps to a different area of Contentstack.
Group | Use it for |
|---|---|
cda | Reading published content through the Content Delivery API |
cma | Creating, updating, publishing, or managing stack content |
cma-extended | Extended CMA operations, such as audits, workflows, versions, or advanced stack operations |
developerhub | Developer Hub APIs |
brandkit | BrandKit tools |
personalize | Personalize management tools |
analytics | Analytics tools |
launch | Launch project tools |
lytics | Lytics tools |
Start with the smallest set of tools you need. For example, if your agent only needs to read published content, start with cda. If it needs to create or update entries, add cma.
A Contentstack tool definition looks like this:
{
"get_all_assets_cdn": {
"name": "get_all_assets_cdn",
"description": "Get all assets from the Content Delivery API.",
"group": "cda",
"mapper": {
"apiUrl": "/v3/assets",
"method": "GET",
"queryParams": {
"limit": "limit",
"skip": "skip",
"include_count": "include_count"
},
"headers": {
"branch": "branch"
}
},
"inputSchema": {
"type": "object",
"properties": {
"limit": {
"type": "number"
},
"skip": {
"type": "number"
},
"include_count": {
"type": "boolean"
},
"branch": {
"type": "string"
}
}
}
}
}There are two important parts:
inputSchema
The inputSchema describes the arguments the tool accepts. You can expose this schema to your MCP server so the client knows how to call the tool.
For example, a tool might accept:
{
"limit": 10,
"include_count": true,
"branch": "main"
}mapper
The mapper tells your server how to turn those arguments into an API request.
A mapper can define:
Field | Purpose |
apiUrl | The Contentstack API path |
method | The HTTP method, such as GET, POST, PUT, or DELETE |
params | Path parameters |
queryParams | Query string parameters |
headers | Headers mapped from tool arguments |
body | The request body mapping |
type | Special request type, such as complex or graphql |
query | GraphQL query string |
variables | GraphQL variable mapping |
Your MCP server does not need to hardcode every Contentstack API. Instead, it can read the mapper and build the correct request dynamically.
Frequently asked questions
What are Contentstack tool definition endpoints?
They are public HTTPS endpoints that return JSON metadata describing tools. They do not execute API requests and do not include credentials.
What is the difference between the cda and cma tool groups?
cda is for reading published content via the Content Delivery API. cma is for creating, updating, publishing, and managing stack content.
What does inputSchema do in a tool definition?
inputSchema defines the arguments a tool accepts as a JSON schema. You can expose it so MCP clients know how to call the tool.
What does the mapper do in a tool definition?
The mapper describes how tool arguments map to an API request, including path, method, query parameters, headers, and body (or GraphQL fields).
Do MCP servers need to hardcode Contentstack APIs when using tool definitions?
No. An MCP server can read the mapper and build requests dynamically, starting with the smallest tool set needed (for example, cda only).