Loading ToolBench
MCP server for Creatio CRM. Connect Claude Desktop, ChatGPT, and GitHub Copilot to Creatio via Model Context Protocol and OData v4.
The server provides 25 tools with generally clear names following verb_noun patterns (get_, create_, update_, delete_, read, list_, describe_, call_, execute_, query_, set_, upsert_, refresh_, dataforge_, global_search, pub_*). However, there are significant gaps in schema definition, parameter documentation, and output schema clarity. Most tools lack visible input schema definitions in the source code provided. Many parameter descriptions are present but vary in quality and specificity. The 'pub-*' tool is particularly problematic, it's dynamically registered with minimal visibility into its actual schema. Error handling guidance is minimal across the board. The server demonstrates competent organization (DataForge tools, CrtMcp publishing, tool preparers) but falls short of production-grade documentation expected for 25+ tools.
Call a Creatio Configuration Service endpoint with a method name and parameters. These are bespoke, tenant-specific endpoints defined in the Creatio instance.
Create a new record in a Creatio OData entity. Returns the Id of the created record.
Create a new system setting in Creatio.
Get lookup/reference data (valid values) for fields in Creatio entities via DataForge
Search for Creatio entities/tables by name or partial match using DataForge AI
Check the status and health of the DataForge service
Missing or incomplete input schemas for most tools. The source code shows parameter descriptions (e.g., entity, filter, filters, select, expand) but does not display the full JSON Schema definitions with type constraints, required fields, or validation rules. Tools like 'create', 'update', 'delete', 'execute-process', 'call-configuration-service' have minimal visible schema detail.
Dynamic pub-* tool registration lacks visibility. Tools published via the CrtMcpPublishingToolPreparer are proxied back to a Creatio app endpoint. Without seeing the actual tool schema and descriptions from the publishing app, these cannot be properly evaluated. The code shows schema conversion via 'jsonSchemaToZodShape' but the actual schemas are remote and not inspectable.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Get detailed metadata for Creatio entities/tables via DataForge (fields, relationships, status)
Discover relationships between Creatio entities/tables via DataForge (foreign keys, lookups)
Delete a record from a Creatio OData entity by Id.
Delete an admin operation (security permission) from Creatio.
Revoke an admin operation (permission) from a user or role in Creatio.
Describe the fields and structure of a Creatio OData entity, optionally via DataForge for richer metadata and relationship discovery
Execute a Creatio business process (workflow) by name and pass parameters to it.
⚠️⚠️⚠️ MANDATORY FIRST STEP ⚠️⚠️⚠️ 🚨 YOU MUST CALL THIS TOOL FIRST before creating ANY Activity, Lead, Opportunity, Case, or other CRM record! WHY CALL FIRST: - Returns the ContactId needed for OwnerId and AuthorId fields - Without this, you CANNOT create activities or CRM records correctly - Activities MUST have valid OwnerId and AuthorId (both = ContactId) - By default, ALL activities/leads/tasks are created FOR THE CURRENT USER 📋 REQUIRED WORKFLOW: Step 1: Call get-current-user-info (no parameters) ← DO THIS NOW! Step 2: Extract contactId from response Step 3: Store contactId in memory for this conversation Step 4: Use contactId as OwnerId and AuthorId in ALL create operations Returns: { "userId": "410006e1-ca4e-4502-a9ec-e54d922d2c00", "contactId": "76929f8c-7e15-4c64-bdb0-adc62d383727", // ← SAVE THIS! "userName": "Current User", "cultureName": "en-US" } USE CASES (when to call): ✅ User asks to create activity/meeting/task/call → CALL THIS FIRST! ✅ User asks to create lead/opportunity/case → CALL THIS FIRST! ✅ User asks who they are → CALL THIS! ✅ Beginning of ANY CRM workflow → CALL THIS FIRST! ❌ Simple queries (read/search) → Not required CRITICAL RULES: - ContactId (NOT userId) goes into OwnerId/AuthorId fields - Cache the ContactId - don't call repeatedly - Default assumption: create records FOR current user - Only change owner if user explicitly says "for [someone else]" Example usage: User: "Create a meeting for tomorrow" YOU: 1) Call get-current-user-info 2) Use contactId for OwnerId and AuthorId 3) Create activity with those IDs
Perform a global search across Creatio entities to find records by keyword or text
List all OData entity sets available in the Creatio instance
Dynamic tools published from Creatio MCP Publishing composable app. Tool names are namespaced as pub-{serverCode}-{toolName} to avoid collisions. Each tool is proxied back to the publishing app's JSON-RPC endpoint.
Query Creatio system settings by code or name. Settings are configuration values stored in the Creatio database.
Query Creatio OData entities with filtering, sorting, selection, expansion, and pagination. Use the structured `filters` parameter (recommended) or raw `filter` (OData $filter clause). Supports both DataService (default) and OData backends.
Refresh the Creatio feature flag cache. Feature flags control feature availability across the system.
Grant an admin operation (permission) to a user or role in Creatio.
Set the value of a Creatio system setting by code.
Update an existing record in a Creatio OData entity by Id. Returns the number of records affected (usually 1).
Update the definition of a system setting (name, type, default value, etc.)
Create or update an admin operation (security permission) in Creatio.
No output schema documentation. The tool descriptions do not declare the structure of returned data. For example, 'read' claims to return matching records but does not document the field names, types, or pagination structure. LLMs cannot plan downstream calls without knowing what fields to expect.
Insufficient error handling guidance. The tool descriptions mention risks (READ_ONLY, WRITE, DESTRUCTIVE) but do not provide recovery instructions. For example, 'delete' offers no guidance on what happens if the record doesn't exist or if the operation fails. LLMs have no actionable next step on error.
Parameter descriptions lack specificity about format and constraints. For example, 'id' parameters (used in update, delete, set-admin-operation-grantee) are described as 'GUID' but no validation rule, regex, or length constraint is provided. Parameters like 'record' in create/update are documented as 'Field values' with minimal guidance on required fields, data types, or ISO 8601 date formats.
'record' parameter in create/update is vague and untyped. The schema shows type 'object' with no properties listed, no required fields declared, and no examples of what fields are accepted. This forces LLMs to guess or infer from tool context, increasing error rates.
Pagination details are absent from read/query tools. Tools like 'read', 'global-search', and 'dataforge-similar-tables' accept 'limit' and 'skip'/'from' parameters but do not document total count behavior, whether cursors are returned, or how to detect end-of-results. This makes it unsafe for agents to iterate through large datasets.
Mandatory call sequence documented via description text rather than dependency metadata. The 'get-current-user-info' tool includes extensive prose about calling it first (all-caps warnings, emoji, step-by-step instructions), which is not machine-parseable. This should be formalized via tool annotations (e.g., dependency flags) or a dedicated dependency graph.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). While each tool is assigned a Risk label (READ_ONLY, WRITE, DESTRUCTIVE), these are not formalized as structured hints that the protocol can understand. The server does not leverage the current MCP spec's tool annotation capability.
Ambiguous parameter names and missing disambiguation. The 'filter' parameter in 'read' states it is 'OData backend ONLY' but the tool defaults to DataService backend. An LLM reading the description might not realize 'filter' is ignored in the common case. Similarly, 'filters' (structured) vs 'filter' (raw) creates confusion, this should be clarified with explicit mutual exclusion rules.