This server provides tools to manage ElmapiCMS projects via MCP, including:
Project: Get info, manage locales (add, set default).
Collections: List, get, create (with initial fields), update, reorder.
Fields: Create, update, reorder fields with various types (text, number, richtext, boolean, date, media, relation, select, group, etc.).
Content entries: Extensive control — list with advanced filtering (13 operators, OR groups, relations), sorting, and pagination; get, create, update (full/partial), publish, unpublish, discard drafts, soft-delete, bulk operations (create, update, delete), link translations, and version history management (list, get, revert, update labels).
Assets: List, get, upload (single/bulk), update metadata, delete.
Webhooks: Full CRUD and delivery log access.
Resources: Consult guides on field types, collections, and query syntax.
An MCP (Model Context Protocol) server that connects AI agents like Cursor and Claude Code to your ElmapiCMS instance. Manage collections, fields, content entries, assets, and webhooks programmatically through natural language.
Variable | Description |
| Instance API root (e.g. |
| Project Sanctum token from Project settings → API Tokens |
| Project UUID from the project home page or Project settings → API Access |
Related MCP server: SitecoreMCP
Add this to your Cursor MCP settings (~/.cursor/mcp.json):
{
"mcpServers": {
"elmapicms": {
"command": "npx",
"args": ["-y", "@elmapicms/mcp-server"],
"env": {
"ELMAPI_BASE_URL": "https://your-domain.com/api",
"ELMAPI_API_KEY": "your-project-api-token",
"ELMAPI_PROJECT_ID": "your-project-uuid"
}
}
}
}claude mcp add elmapicms \
-e ELMAPI_BASE_URL=https://your-domain.com/api \
-e ELMAPI_API_KEY=your-project-api-token \
-e ELMAPI_PROJECT_ID=your-project-uuid \
-- npx -y @elmapicms/mcp-server.test domains)If your instance uses a self-signed certificate (e.g. Laravel Herd), you may need:
"env": {
"ELMAPI_BASE_URL": "https://myproject.test/api",
"ELMAPI_API_KEY": "your-project-api-token",
"ELMAPI_PROJECT_ID": "your-project-uuid",
"NODE_TLS_REJECT_UNAUTHORIZED": "0"
}Prefer fixing local CA trust (e.g. node --use-system-ca) over disabling TLS verification in production configs.
get_project — Get project information (default_locale, locales, etc.)
add_project_locale — Add a locale code to the project (requires admin)
set_default_project_locale — Set the default locale (requires admin)
Removing locales is intentionally not exposed here (use Project settings → Localization in the dashboard, or the REST/SDK APIs).
list_collections — List all collections
get_collection — Get a collection with its full field schema
create_collection — Create a collection (with optional batch field creation)
update_collection — Update a collection's name and slug
reorder_collections — Reorder collections
create_field — Add a field to a collection
update_field — Update a field
reorder_fields — Reorder fields within a collection
list_entries — List entries with advanced filtering (where with 13 operators, OR groups, relation filtering), sorting, pagination, count, and first
get_entry — Get a single content entry
create_entry — Create a content entry
update_entry — Update a content entry
patch_entry — Partially update an entry (HTTP PATCH; merge only the fields you send)
publish_entry — Publish the draft as a new immutable version (update)
unpublish_entry — Clear the live published pointer; versions retained (update)
discard_entry_draft — Discard unpublished draft changes (update)
delete_entry — Soft-delete a content entry (moves to trash)
bulk_create_entries — Create multiple entries atomically
bulk_update_entries — Update multiple entries atomically by UUID
bulk_delete_entries — Delete multiple entries atomically by UUID
link_entry_translation — Link two entries (different locales) into the same translation group (POST …/link-translation; requires update)
list_entry_versions — List version history for an entry
get_entry_version — Fetch one version by number (includes snapshot payload)
revert_entry_version — Restore draft from a prior snapshot and publish (update)
update_entry_version_label — Edit label/description on a version; snapshot unchanged (update)
Content API shape: Each entry has uuid, locale, published_at, and fields (custom field values). Field names are kebab-case. Richtext write format follows editor.mode: HTML string or { html, json } for lexical; markdown string when mode is markdown. MCP create_field / create_collection (and richtext update_field) default omitted editor.mode to markdown. Pass mode: 'lexical' for Lexical. Never write markdown into a lexical field. Read shape follows editor.outputFormat. Relation fields return nested entry objects (or arrays for one-to-many) on read; on write send only the related entry’s UUID or numeric id (never the full nested object from a previous get_entry). get_entry supports translation_locale, exclude, timestamps, and state query parameters.
Save ≠ publish: create_entry / update_entry / patch_entry save the draft only. state=published list/get keep serving the last snapshot until you call publish_entry.
Asset URLs: The API returns url, thumbnail_url, and original_url as stable links (optional ?variant=thumbnail or ?variant=original).
list_assets — List assets with pagination
get_asset — Get an asset by UUID or filename
upload_asset — Upload a file as an asset
bulk_upload_assets — Upload multiple files atomically
bulk_update_asset_metadata — Update metadata for multiple assets atomically
delete_asset — Delete an asset
list_webhooks — List all webhooks for the project
get_webhook — Get a webhook by UUID
create_webhook — Create a webhook for content and auth events (name, url, events, sources; optional description, secret, payload, status, collection_ids)
update_webhook — Update a webhook by UUID (same fields as create)
delete_webhook — Delete a webhook by UUID
list_webhook_logs — List delivery logs for a webhook (uuid; optional paginate, page)
The server exposes three reference resources that AI agents can read for context:
Field Types Reference (elmapicms://field-types) — Complete reference of all 16 field types, their options, validations, and common patterns.
Collections Guide (elmapicms://collections-guide) — Guide for working with collections, singletons, reserved slugs, and best practices.
Query Reference (elmapicms://query-reference) — Full documentation for content queries: where filters with 13 operators, OR groups, relation filtering, sorting, pagination, and examples.
Your project API token needs the appropriate abilities for the tools you want to use:
Ability | Tools |
| list/get collections, entries, assets, webhooks; webhook logs |
| create entries, upload assets, create webhooks |
| update entries, publish/unpublish/discard draft, |
| delete entries, delete assets, delete webhooks |
| create/update/reorder collections and fields; add/set default project locales (MCP does not expose locale removal) |
Create the token in the ElmapiCMS dashboard under Project settings → API Tokens. Copy the Project ID from the project home page or Project settings → API Access when you configure this server.
Each MCP entry connects to a single ElmapiCMS project. To work with multiple projects, add separate entries in your MCP config with different env values.
MIT
Create a new collection. Optionally include field definitions to create the collection with its full schema in a single request.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name (max 60 chars) | |
| slug | Yes | URL-friendly identifier, kebab-case (max 60 chars) | |
| is_singleton | No | If true, collection can only have one entry | |
| fields | No | Array of field definitions to create with the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description is minimal and does not disclose behavioral traits such as idempotency, error handling (e.g., duplicate slug), or authentication requirements. For a creation tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 18 words, no redundant information. Front-loaded with purpose. Could slightly improve by adding a brief note on constraints, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters including nested objects, the description is too sparse. It does not mention return values, error scenarios, or how the tool fits with siblings like create_field. Incomplete for an agent to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds little beyond 'Optionally include field definitions', which is already clear from the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Create' and resource 'collection', and distinguishes from siblings like create_entry and create_field by specifying the action is on collections. The optional field definitions add specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like creating fields separately after collection creation. Lacks context for choosing between including fields here or using create_field later.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new content entry in a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection_slug | Yes | The collection slug | |
| data | Yes | Object where keys are field names and values are the content (e.g. { title: 'My Post', slug: 'my-post' }) | |
| status | No | Publication status: 'published' or 'draft' (default) | |
| locale | No | Locale code (e.g. 'en') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It only repeats the basic purpose and offers no details on idempotency, side effects, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence without wasted words, but under-specified. Could include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, nested objects, and no output schema, the description is too minimal. It lacks explanation of return values or behavior beyond creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'content entry', and the scope 'in a collection'. It distinguishes from sibling tools like delete_entry and update_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as update_entry or list_entries. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new field to a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection_slug | Yes | The slug of the collection to add the field to | |
| type | Yes | Field type: text, number, richtext, boolean, date, media, relation, select, longtext, group, etc. | |
| label | Yes | Display label (max 60 chars) | |
| name | Yes | Field identifier in kebab-case (max 60 chars) | |
| description | No | Field description | |
| placeholder | No | Placeholder text | |
| options | No | Field-specific options (e.g. { repeatable: true } for group fields) | |
| validations | No | Validation rules (e.g. { required: { status: true, message: 'Required' } }) | |
| parent_field_id | No | Internal ID of a group field to nest this field under |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It merely states the action without any information about side effects, reversibility, permissions, or output behavior. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets to the point. It is appropriately brief, though could benefit from a little more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite moderate complexity (9 parameters, nested objects) and no output schema, the description is minimal. It fails to explain important aspects like validation, success responses, or consequences of creation, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its 9 parameters, so the baseline is 3. The description does not add any additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' and a clear resource 'new field to a collection', which distinctively indicates the tool's function. It is unambiguous and distinguishes from sibling tools like update_field and reorder_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_field or reorder_fields. There is no mention of prerequisites, limitations, or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an asset by UUID
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | The asset UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the basic action without disclosing important behavioral traits like irreversibility, cascading effects, or authorization requirements. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but perhaps overly minimal given the importance of clarity for a delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description lacks critical context for a deletion tool (e.g., irreversibility, permissions, effects on related data). With no annotations, the description should provide more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a basic description ('The asset UUID'). The tool description adds no additional meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (delete), resource (asset), and method (by UUID). It is unambiguous and distinguishes from sibling tools like delete_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor prerequisites or conditions for safe use. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Soft-delete a content entry (moves to trash). Can be restored from the admin panel.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_slug | Yes | The collection slug | |
| uuid | Yes | The entry UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It discloses the soft-delete behavior and restore possibility, but lacks details on permissions, reversal window, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, directly conveys the essential behavioral nuance (soft-delete, restorable). Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two well-described parameters and no output schema, the description covers the key behavioral aspects. Could mention return value, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters. The tool description adds no additional parameter context beyond what schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (soft-delete), the resource (content entry), and the consequence (moves to trash, restorable). It distinguishes from sibling 'delete_asset' by specifying 'entry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'update_entry' or 'delete_asset'. The soft-delete nature is mentioned but not framed as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an asset by its UUID or by filename
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Asset UUID or filename | |
| by_name | No | If true, looks up by filename instead of UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention read-only nature, authentication requirements, error handling (e.g., asset not found), or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. Every part is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with no output schema, the description is adequate but lacks details on return format, error cases, and what constitutes an 'asset'. Given the low complexity, it meets minimum viability but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds marginal value by explaining the two lookup methods. However, it does not provide additional details beyond what is already in the schema (e.g., acceptable formats for identifier). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'asset', and specifies the two lookup methods (UUID or filename), which distinguishes it from sibling tools like list_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., list_assets) or how to choose between the two lookup methods. The usage context is implied but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single collection with its full field schema by slug
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The collection slug (e.g. 'blog-posts') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation returning a collection, but doesn't disclose potential side effects, permissions, or rate limits. The behavior is clear but lacks extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is complete. It clearly specifies what is returned and how to specify the collection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds minimal extra meaning beyond the schema's parameter description ('by slug' reinforces but does not expand).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('a single collection'), and the distinguishing feature ('with its full field schema by slug'). This differentiates it from sibling tools like 'list_collections'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a specific collection's details, but does not explicitly state when not to use it or mention alternatives. The sibling list provides implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single content entry by UUID
| Name | Required | Description | Default |
|---|---|---|---|
| collection_slug | Yes | The collection slug | |
| uuid | Yes | The entry UUID | |
| locale | No | Locale code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose behavior on missing entries, permissions required, or response format. For a simple read, this is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is concise but could be slightly improved by front-loading the UUID essentiality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description does not explain return format, error conditions, or edge cases, making it incomplete for a holistic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters (collection_slug, uuid, locale). The description adds no additional parameter meaning beyond the schema, achieving the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single content entry by UUID' clearly identifies the verb (Get), resource (single content entry), and identifier (UUID). It distinguishes from sibling tools like list_entries (plural) and get_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_asset or list_entries. The implied usage is for fetching a single entry by UUID, but no when-not or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current ElmapiCMS project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only says 'Get information', implying a read operation, but fails to mention side effects, performance, authentication needs, or what 'current' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no waste. Could be improved by adding a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a sparse description, the agent lacks information about what 'information' includes. For a no-parameter tool, more context about the return value is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description cannot add meaning. Baseline of 4 is appropriate since no additional description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'the current ElmapiCMS project', distinguishing it from siblings like get_collection or get_entry. However, 'information' is vague; specifying 'metadata' or 'details' would be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_collection or get_entry. The description does not mention any prerequisites or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List assets in the project with optional pagination
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| per_page | No | Items per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not reveal behavioral details like sorting, max page size, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is one concise sentence. Could include more details without sacrificing brevity, but no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. Missing key details like default values, maximum per_page, return format, or error handling. Incomplete for a listing endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for page and per_page. Description adds only the phrase 'optional pagination', which does not significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists assets in the project, distinguishing it from CRUD siblings like create_asset, delete_asset, etc. Somewhat generic but sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use list_assets vs get_asset or other listing tools. No context about filtering or when pagination is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all collections in the project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description is the sole source. It only states the action but does not disclose potential behaviors like authentication requirements, rate limits, or the nature of the return data. However, for a simple list operation, this is marginally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with no fluff. It is front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should at least hint at what is returned (e.g., 'returns collection names and IDs'). It only says 'list all collections', leaving the return format ambiguous. For a list tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline score is 4. The description does not need to add parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all collections, with a specific verb and resource. It distinguishes from 'get_collection' (single) and 'create_collection'. However, it does not specify any filtering capabilities, which are absent anyway.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_collection' or 'list_entries'. It does not mention that it returns all collections without any filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List content entries for a collection with advanced filtering, sorting, and pagination. Use the 'where' parameter for powerful queries. Read the 'query-reference' resource for full documentation on operators and examples.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_slug | Yes | The collection slug | |
| where | No | Filter conditions as a nested object. Supports operators: eq, lt, lte, gt, gte, not, like, in, not_in, null, not_null, between, not_between. Simple: { "status": "published" }. With operators: { "price": { "lt": 50 }, "title": { "like": "news" } }. OR group: { "or": [{ "tags": "clearance" }, { "campaign": { "name": "Summer" } }] }. Relation filter: { "author": { "name": { "eq": "John" } } }. Core columns (id, uuid, locale, status, created_at, updated_at, published_at) can be filtered directly. | |
| locale | No | Filter by locale (e.g. 'en') | |
| state | No | Filter by state: 'only_draft' or 'with_draft'. Defaults to published entries only. | |
| sort | No | Sort by field:direction, comma-separated for multiple. Examples: 'created_at:desc', 'title:asc,created_at:desc'. Supports core columns (id, created_at, updated_at, published_at) and custom field names. | |
| paginate | No | Enable pagination with N items per page. Returns paginated response with meta data. Overrides limit/offset. | |
| limit | No | Limit the number of results (ignored if paginate is set) | |
| offset | No | Skip N results (requires limit to be set) | |
| first | No | If true, return only the first matching entry as a single object instead of an array | |
| count | No | If true, return only the count of matching entries: { count: N } | |
| exclude | No | Comma-separated field names to exclude from response (e.g. 'content,excerpt') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions surface features. It does not disclose side effects, idempotency, authentication needs, or performance implications beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the main action and direct to detailed docs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, nested objects, no output schema), the description is incomplete. It omits return format, pagination meta, error handling, and example usage, leaving the agent to infer from schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds minor value by summarizing filtering/sorting/pagination and referencing external docs, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'content entries for a collection', distinguishing it from sibling tools like get_entry (single) or create_entry. However, it does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using the 'where' parameter but provides no guidance on when to use this tool vs. others (e.g., get_entry for single entries) or prerequisites. No exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the display order of collections
| Name | Required | Description | Default |
|---|---|---|---|
| collections | Yes | Array of { uuid, order } objects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'update the display order' but does not disclose the effect on existing orders, whether it replaces the entire order, or any required permissions. No annotations are present to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (6 words), which is concise but lacks important details. It earns its place but could benefit from more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficiently complete. It does not clarify the behavior of the order update, e.g., whether it is incremental or full replacement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full documentation for the single parameter 'collections', including its structure and fields. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates the display order of collections, which matches the title. However, it does not distinguish from sibling tools like update_collection, though the purpose is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_collection or reorder_fields. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the display order of fields within a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection_slug | Yes | The collection slug | |
| fields | Yes | Array of { uuid, order } objects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It indicates a mutation (update) but fails to specify whether the order is fully replaced or merged, constraints on order values, or the effect on existing fields. This leaves significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but omits critical information. It prioritizes brevity over completeness, making it less helpful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested array parameter, no output schema, no annotations), the description is insufficient. It does not mention the effect on existing field ordering, idempotency, or error cases, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both parameters. The description adds no extra meaning beyond the schema, such as the fact that 'fields' is an array of objects with uuid and order. Hence a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'display order of fields within a collection', making the purpose clear. However, it does not explicitly distinguish from the sibling tool 'reorder_collections', though the resource difference is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites (e.g., collection must exist) or conditions for reordering. The description lacks usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the name and slug of an existing collection
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Current slug of the collection to update | |
| name | Yes | New display name | |
| new_slug | Yes | New slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only states 'update', which implies mutation, but does not mention potential side effects, permission requirements, or reversibility. For a destructive operation, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and target, containing no extraneous words. It is highly concise while conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of the tool (update two fields) and no output schema, the description is minimally adequate. However, it could be improved by mentioning what the tool returns or any prerequisites (e.g., collection existence).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond the schema, merely restating 'name and slug' without additional clarification or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing collection's name and slug, distinguishing it from siblings like create_collection (creation) and get_collection (read). The verb 'Update' and resource 'collection' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the sibling list is available, the description lacks any explicit context, exclusions, or when-not scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing content entry
| Name | Required | Description | Default |
|---|---|---|---|
| collection_slug | Yes | The collection slug | |
| uuid | Yes | The entry UUID | |
| data | Yes | Object with field names and their new values | |
| status | No | Publication status: 'published' or 'draft' | |
| locale | No | Locale code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only says 'update', but does not mention idempotency, error states (e.g., what happens if the entry does not exist), permissions required, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the tool's purpose. It is front-loaded and avoids unnecessary words. However, it could be slightly expanded to include critical context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (one nested), no output schema, and multiple sibling crud tools, the description lacks completeness. It does not explain return values, update behavior (partial vs full), or validation rules. More detail is needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all parameters have descriptions in the input schema itself. The description adds no additional semantic value beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing content entry', making it clear what the tool does. However, it does not differentiate itself from sibling tools like update_field or update_collection, which also perform updates on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_entry or delete_entry. There are no prerequisites mentioned (e.g., that the entry must exist before updating), and no context on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing field on a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection_slug | Yes | The collection slug | |
| field_uuid | Yes | The UUID of the field to update | |
| type | Yes | Field type | |
| label | Yes | Display label | |
| name | Yes | Field identifier in kebab-case | |
| description | No | Field description | |
| placeholder | No | Placeholder text | |
| options | No | Field-specific options | |
| validations | No | Validation rules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'update', implying mutation, but does not disclose behavioral traits such as idempotency, validation, side effects, or required permissions. Since no annotations are provided, the description fails to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded. It earns its place without redundancy, but could benefit from slightly more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters including nested objects and no output schema, the description is inadequate. It does not explain return values, behavior of nested options/validations, or how updates are applied, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds no additional meaning beyond the schema, which is acceptable when coverage is high. However, it does not clarify which parameters are typically needed or optional constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'update' and the resource 'existing field on a collection'. It is specific enough to distinguish from sibling tools like create_field or delete_asset, though it does not elaborate on what aspects are updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites, or when not to use it. There is no mention of alternatives or context that would help an agent select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local file as an asset. Provide the absolute file path.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file to upload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility to disclose side effects, permissions, or error handling. It only mentions 'Upload', implying mutation, but lacks details on file size limits, supported types, success/failure behavior, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences), but it omits important behavioral context. While brevity is valued, it compromises completeness for a mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain return values, error conditions, and execution behavior. It fails to do so, leaving significant gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description. The description adds 'Provide the absolute file path,' which largely echoes the schema. No additional semantic meaning is provided beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool uploads a local file as an asset, which is distinct from sibling tools like delete_asset or list_assets. However, it could be more explicit about the nature of assets in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. The description simply states what it does, without helping the agent decide when to choose upload over other asset-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0create_collectioncreate_entrycreate_fielddelete_assetdelete_entryget_assetget_collectionget_entryget_projectlist_assetslist_collectionslist_entriesreorder_collectionsreorder_fieldsupdate_collectionupdate_entryupdate_fieldupload_assetAll 18 tools target distinct resources and actions (e.g., create_collection vs create_entry vs create_field), with no overlapping purposes. Each tool has a clear and separate role.
All tool names follow a consistent verb_noun pattern in lowercase snake_case (e.g., create_collection, list_entries, upload_asset), with no deviations or style mixing.
With 18 tools, the count is slightly above the ideal 3-15 range but still reasonable for a full-featured CMS server. Each tool serves a specific function without bloat.
CRUD coverage is strong for entries and assets, but notable gaps exist: no delete_collection or delete_field tools, and no update_asset. Reorder operations are included but are less critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/elmapicms/elmapicms-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
