mcp-creatio
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CREATIO_LOGIN | No | Username for legacy auth | |
| READONLY_MODE | No | Set 'true' to disable create/update/delete operations | |
| CREATIO_BASE_URL | Yes | Your Creatio instance URL | |
| CREATIO_PASSWORD | No | Password for legacy auth | |
| CREATIO_CLIENT_ID | No | OAuth2 client credentials ID | |
| CREATIO_CODE_SCOPE | No | OAuth2 scope (e.g. offline_access ApplicationAccess_yourappguid) | |
| CREATIO_ID_BASE_URL | No | Identity Service URL (if separate from main Creatio instance) | |
| CREATIO_CLIENT_SECRET | No | OAuth2 client credentials secret | |
| MCP_CREATIO_LOG_LEVEL | No | Log verbosity: silent (default), error, warn, info | |
| CREATIO_CODE_CLIENT_ID | No | OAuth2 authorization code client ID | |
| CREATIO_CODE_REDIRECT_URI | No | OAuth2 redirect URI (e.g. http://localhost:3000/oauth/callback) | |
| CREATIO_CODE_CLIENT_SECRET | No | OAuth2 authorization code client secret |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get-current-user-infoA | Returns the Creatio user this server acts as: { success, userInfo: { id, contactId, contactName, email, cultureInfo, timeZone, utcOffset, now, today, userRoles, ... } }. Call it once before creating records owned by the user — owner/author lookups (OwnerId, AuthorId) take |
| list-entitiesA | Entity (object schema) names available to this server — 1000+ in all, so pass |
| describe-entityA | Columns of one entity ({ entity: "Contact" }) — names, types, required/nullable and its key — to plan a read or a write without guessing column names. Response: { source, entitySet, ... } where |
| readA | Query records of one entity: filter, pick columns, sort, page, count. Find the entity first if unsure (dataforge-similar-tables, global-search, list-entities) and check its columns with describe-entity. |
| query-sys-settingsA | Current values and metadata of system settings by code. Response: the platform's answer — a success flag, a values map by code (each with its |
| get-guideA | Step-by-step guidance for multi-step Creatio work — read the matching guide before such a task, once per conversation. Topics: query-guide (How to find the right entity and columns, read with filters / related columns / sorting / paging / counting, and present results with record links and attachments); create-activity-guide (Tasks, meetings and calls: owner, type and category ids, times, participants, and confirming to the user); datetime-guide (How record dates follow the user’s Creatio time zone, with write, filter and read examples); contactid-guide (Which id a person field takes (a Contact id for owners/authors, a SysAdminUnit id for users and roles in permissions) and how to get the current user and other people); tagging-guide (Adding, listing and removing tags in the object’s own tag list or Creatio’s shared tags, and choosing between them); sys-settings-guide (Finding, creating and changing system settings: value types, lookup settings, definitions); feature-toggle-guide (Listing, inspecting and changing feature toggles (default state and per-user/role overrides) on the DataService and OData backends); admin-operation-guide (Creating system operations (SysAdminOperation) and granting or denying them to users and roles). Returns the guide as Markdown. |
| get-record-urlA | { url } that opens the record in Creatio; Creatio picks the right page (classic or Freedom UI). Give it to the user whenever you refer to a specific record. A signed-out visitor goes through login first; an object without a record page opens the home page. Built locally — no request to Creatio. |
| list-record-filesA | Files and links attached to one record, from both places Creatio keeps them (the object's File table and SysFile), newest first. Response: { files: [{ id, name, kind: "file" | "link" | "object-link", size, createdOn, storage, downloadUrl? (files), url? (links) }], hasMore }. Metadata only — the content is never read. |
| list-featuresA | Feature toggles from every source — DB rows and also web.config, package metadata and GlobalAppSettings features — ordered by code. Each: { code, name, description?, source, enabledByDefault, enabledForCurrentUser }. Response: { items, hasMore } — page with |
| get-featureA | One feature (fields as in list-features) plus |
| createA | Create one record: { entity, data } → the new record's id. Check required columns and types with describe-entity first; send only the columns you set. Owner/author lookups (OwnerId, AuthorId, …) of records the user creates for themselves get their contact id — |
| updateA | Change columns of one record by id; columns you leave out keep their values. Resolve lookup ids instead of guessing them (e.g. a new StatusId from ActivityStatus via read); owner/user lookups take a contact id (get-guide: contactid-guide). Example: { entity: "Activity", id: "", data: { StartDate: "2026-03-02T12:00:00", DueDate: "2026-03-02T12:30:00" } } (the user's Creatio time zone). |
| deleteA | Permanently delete one record by id. Confirm with the user first: say which record (entity, name, id) will be deleted and wait for an explicit yes. Related records may block the delete (Creatio then reports a reference error) or be removed with it, depending on the object. |
| execute-processA | Start a Creatio business process by its schema name, with optional parameters, and return its result. A process can change any data it is designed to — make sure the user wants it run. User/contact parameters take a contact id (get-guide: contactid-guide). |
| set-sys-settings-valueA | Set the values of one or more existing system settings in one request; returns the platform's answer. System settings can change how the whole instance behaves — confirm the change with the user. |
| create-sys-settingB | Create a new system setting (its definition) and optionally set its first value. Value types and lookup settings: get-guide: sys-settings-guide. |
| update-sys-setting-definitionA | Change a setting's metadata (name, description, value type, cache / personal flags, lookup schema) — not its value (use set-sys-settings-value). See get-guide: sys-settings-guide. |
| refresh-feature-cacheA | Make Creatio re-read feature-toggle states for all users. set-feature-state already does this; use it after changing |
| set-feature-stateA | Change a feature's default state, or override it for one user/role, for features from any source. The first change to a web.config / metadata feature gives it a DB row, which then takes precedence over that source (the Creatio feature page behaves the same). Returns the feature as in get-feature plus |
| upsert-admin-operationA | Create a system operation (SysAdminOperation) — omit |
| delete-admin-operationA | Delete system operations by id, together with their grants. The generic delete tool is blocked for this table. Confirm with the user first. See get-guide: admin-operation-guide. |
| set-admin-operation-granteeA | Allow or deny a system operation for users/roles. Repeating it for the same operation and user/role updates the existing grant instead of adding another. See get-guide: admin-operation-guide. |
| delete-admin-operation-granteeA | Delete grant rows by id, so the operation is neither allowed nor denied explicitly for those users/roles. To switch allow ↔ deny use set-admin-operation-grantee. |
| call-configuration-serviceA | Escape hatch: call any configuration-package REST method (/0/rest//) when no dedicated tool covers the task — those validate input and explain their effects, so prefer them. The method may change data. Response: { status, contentType, body } (JSON parsed). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| query-guide | How to find the right entity and columns, read with filters / related columns / sorting / paging / counting, and present results with record links and attachments |
| create-activity-guide | Tasks, meetings and calls: owner, type and category ids, times, participants, and confirming to the user |
| datetime-guide | How record dates follow the user’s Creatio time zone, with write, filter and read examples |
| contactid-guide | Which id a person field takes (a Contact id for owners/authors, a SysAdminUnit id for users and roles in permissions) and how to get the current user and other people |
| tagging-guide | Adding, listing and removing tags in the object’s own tag list or Creatio’s shared tags, and choosing between them |
| sys-settings-guide | Finding, creating and changing system settings: value types, lookup settings, definitions |
| feature-toggle-guide | Listing, inspecting and changing feature toggles (default state and per-user/role overrides) on the DataService and OData backends |
| admin-operation-guide | Creating system operations (SysAdminOperation) and granting or denying them to users and roles |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Tool purposes are mostly cleanly separated by resource: generic record CRUD, feature toggles, system settings, admin operations, and processes each form a distinct group. A few near-overlaps remain — delete vs. delete-admin-operation (generic blocked, explained), and refresh-feature-cache vs. set-feature-state (which already clears the cache) — but descriptions disambiguate them well enough.
Everything is uniformly kebab-case with a verb-first pattern (list-entities, describe-entity, set-feature-state, delete-admin-operation-grantee), which is easy to scan. Minor deviation: the generic record tools use bare verbs (read, create, update, delete) while every other tool carries a resource noun, slightly breaking the parallel structure.
24 tools is on the heavy side, but the server covers several genuinely distinct sub-domains (records, processes, files, system settings, feature toggles, admin operations), and each group needs its few operations. No obvious filler except refresh-feature-cache, which is largely a fallback for direct data edits.
Record CRUD, schema discovery, filtering/paging/counting, process execution, feature toggles, system settings, and admin-operation grants are all covered end to end with guides for multi-step work. Gaps are minor: no system-setting deletion, file attachments are list-only (no upload/attach), and feature overrides are removed only via raw record CRUD rather than a dedicated tool.