Provides tools for managing BPMN processes, user tasks, and forms in Camunda Platform, allowing AI agents to deploy, start, monitor processes, and handle tasks.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Camunda Engine MCP Server List all running process instances"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants to interact with Camunda Platform workflow engine. Provides 21 specialized tools for complete workflow automation and process management.
✅ PRODUCTION READY - Fully tested, containerized, and ready for deployment.
git clone <repo-url>
cd camunda-engine-mcp
docker-compose up -dAdd to your Claude Desktop MCP settings:
{
"mcpServers": {
"camunda": {
"command": "docker",
"args": [
"exec", "-i",
"-e", "CAMUNDA_BASE_URL=https://your-camunda-instance.com/engine-rest",
"-e", "CAMUNDA_USERNAME=your-username",
"-e", "CAMUNDA_PASSWORD=your-password",
"camunda-mcp-server",
"node", "build/index.js"
]
}
}
}Completely close and restart Claude Desktop to load the MCP server.
Try these commands in Claude Desktop:
Show me all available processes in CamundaGet the list of current tasks from CamundaDeploy BPMN from file /workspace/bpmn/simple-process.bpmnRelated MCP server: n8n-manager-mcp
21 MCP Tools for complete Camunda workflow management
Process Management - Deploy, start, monitor BPMN processes
Task Management - Handle user tasks and forms
Large File Support - Deploy big BPMN files via file paths
Production Ready - Docker, monitoring, health checks
Real-time Integration - Direct connection to live Camunda instances
For large BPMN/form files, place them in directories:
./bpmn-files/your-process.bpmn # → /workspace/bpmn/your-process.bpmn
./forms/your-form.form # → /workspace/forms/your-form.formThen use file paths instead of content:
Deploy BPMN from file /workspace/bpmn/your-process.bpmnSetup Guide - Detailed configuration and all 21 tools
Troubleshooting - Common issues and solutions
Testing Guide - Comprehensive testing framework
Production Report - Production readiness details
CAMUNDA_BASE_URL=https://your-camunda-instance.com/engine-rest
CAMUNDA_USERNAME=your-username
CAMUNDA_PASSWORD=your-passworddocker exec camunda-mcp-server npm run health-checkIssues: Check Troubleshooting Guide
Setup: See Setup Guide
Testing: Run npm run health-check
Ready to automate your workflows with AI? Start with the Quick Start above! 🚀
Activate a suspended process instance
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | The id of the process instance to activate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the basic function without revealing side effects, permissions, or constraints. Minimal behavioral disclosure.
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 concise (one sentence) and directly states the tool's purpose. Could include additional 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?
Given the simplicity (1 param, no output schema), the description is adequate but lacks context on prerequisites or expected behavior after activation.
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 a description. The tool description adds no extra meaning beyond what the schema already provides for the single parameter.
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 ('Activate') and the resource ('a suspended process instance'), distinguishing it from sibling tools like suspendProcessInstance or startProcessInstance.
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 for suspended instances but lacks explicit guidance on when to use vs alternatives (e.g., suspendProcessInstance). 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.
Complete a task
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The id of the task to complete. | |
| variables | No | A JSON object containing variable key-value pairs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., marking task as completed), required permissions, or whether the operation is idempotent. The name suggests a write operation, but details are absent.
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 (3 words), but it is under-specified rather than efficiently informative. It sacrifices substance for brevity.
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 lack of output schema and the complexity of sibling tools, the description fails to explain the return value or what 'complete' specifically does. It is incomplete for an agent to correctly invoke and interpret 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 description coverage is 100%, so the schema already documents both parameters (taskId, variables). The description adds no additional meaning beyond the schema, earning the baseline score.
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 'Complete a task' provides a verb and resource, but it is vague and does not distinguish from similar sibling tools like submitTaskForm or startProcessInstance. It lacks specificity about what 'complete' entails 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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives such as submitTaskForm or getTasks, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a deployment by id
| Name | Required | Description | Default |
|---|---|---|---|
| deploymentId | Yes | The id of the deployment to delete. | |
| cascade | No | If true, cascade deletion to process instances, history process instances and jobs. | |
| skipCustomListeners | No | If true, custom listeners will not be invoked. | |
| skipIoMappings | No | If true, input/output mappings will not be invoked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits beyond the action. It omits side effects, permissions, or default behavior of optional parameters.
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 (five words) with no wasted text. However, it could be slightly expanded to include essential context.
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, output schema, and four parameters including a required one, the description is too sparse. It does not cover return values, side effects, or conditions for success.
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 tool description adds no additional meaning beyond what the schema already provides, so 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 states exactly what the tool does: 'Delete a deployment by id'. It uses a specific verb and resource, and distinguishes from siblings like deleteProcessInstance.
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 context about prerequisites, effects of parameters like cascade, or when deletion might fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a process instance
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | The id of the process instance to delete. | |
| reason | No | A reason for deletion. | |
| skipCustomListeners | No | If true, custom listeners will not be invoked. | |
| skipIoMappings | No | If true, input/output mappings will not be invoked. | |
| skipSubprocesses | No | If true, subprocesses will not be deleted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It fails to mention that deletion is irreversible, whether it cascades to subprocesses or tasks, required permissions, or the return value (e.g., void or confirmation). This is a critical gap 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 extremely concise (one sentence, 4 words). While brevity can be positive, here it sacrifices essential details. The structure is front-loaded but incomplete. Every word is necessary if it were sufficient, but it is not, so conciseness alone does not earn a higher score.
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 (delete operation with 5 parameters, no output schema, no annotations), the description is insufficient. It does not explain what happens upon deletion, return semantics, or side effects. An agent would need additional information to safely invoke this 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% (all 5 parameters are described). The description adds no additional meaning beyond what the schema already provides. According to the rules, when schema coverage is high (>80%), the baseline is 3, and since there is no extra value, the score remains 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 clearly states the verb 'Delete' and the resource 'process instance', making the action unambiguous. However, it does not differentiate from sibling tools beyond the name, but the name itself is distinctive enough (e.g., 'deleteProcessInstance' vs 'activateProcessInstance'). A slightly more specific phrasing like 'permanently delete' would improve clarity.
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 like 'suspendProcessInstance' or 'completeTask'. There is no mention of prerequisites, conditions, or when not to delete a process instance. The description lacks contextual decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a BPMN process definition from content or file
| Name | Required | Description | Default |
|---|---|---|---|
| deploymentName | Yes | The name of the deployment. | |
| bpmnContent | Yes | The BPMN XML content as a string, OR path to a BPMN file (e.g., '/workspace/process.bpmn'). | |
| fileName | No | The name of the BPMN file (e.g., 'process.bpmn'). Auto-detected from file path if not provided. | |
| enableDuplicateFiltering | No | Enable duplicate filtering to avoid redeploying unchanged resources. | |
| deployChangedOnly | No | Deploy only changed resources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states deployment method without disclosing side effects (e.g., duplicate handling, success/error responses, required permissions). Minimal behavioral info beyond parameter names.
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 filler. Front-loaded with key action and resource. Efficient and to the point.
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 5 parameters, no output schema, and no annotations, description is insufficient. Omits return value, error handling, idempotency, and deployment lifecycle context.
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. Description adds little extra meaning beyond schema; 'from content or file' hints at parameter usage but is already obvious from parameter descriptions.
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's function: deploying a BPMN process definition from content or file. It distinguishes from siblings like deployForm and deleteDeployment by specifying the resource type (BPMN process definition).
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 deployForm or startProcessInstance. No prerequisites, context, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy a Camunda Form from content or file
| Name | Required | Description | Default |
|---|---|---|---|
| deploymentName | Yes | The name of the deployment. | |
| formContent | Yes | The Camunda Form JSON content as a string, OR path to a form file (e.g., '/workspace/form.form'). | |
| fileName | No | The name of the form file (e.g., 'form.form'). Auto-detected from file path if not provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'deploy' without explaining idempotency, overwrite behavior, or side effects. The agent gets no insight into potential risks or limitations.
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?
A single sentence that efficiently conveys the core action. No unnecessary words or repetition.
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?
Without output schema or annotations, the tool description is the only source of completeness. It fails to explain return values, error states, or the file resolution mechanism. The agent is left wondering what happens after deployment.
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 baseline is 3. The description adds value by clarifying that formContent can be JSON content or a file path, and that fileName is auto-detected. This enriches the parameter meaning beyond the schema alone.
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 'deploy' and the resource 'Camunda Form', and distinguishes from sibling tools by specifying 'form' vs BPMN. It also mentions two modes: from content or file.
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 deployBpmn. Missing context on prerequisites, such as required authentication or file path conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get activity instances for a process instance
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | The id of the process instance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral aspects. It states 'Get' implying a read operation, but lacks details on return format, pagination, or any side effects. This is insufficient for a tool with no annotations.
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 with a single sentence that conveys the core function without any unnecessary words. Every word 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?
For a simple tool with one required parameter and no output schema, the description provides the basic purpose. However, it lacks behavioral details and usage guidance, leaving room for improvement.
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 single parameter 'processInstanceId' is fully described in the input schema (100% coverage). The description does not add any extra meaning beyond the schema, meeting the baseline expectation.
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 'activity instances' with the context 'for a process instance'. However, it does not distinguish this tool from siblings like 'getProcessInstances' or 'getTasks', so it could be clearer.
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. The description only implies that it is used to retrieve activity instances, but no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get resources of a deployment
| Name | Required | Description | Default |
|---|---|---|---|
| deploymentId | Yes | The id of the deployment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description merely repeats the name. Does not disclose read-only nature, behavior for invalid IDs, or any potential side effects beyond the implied fetch 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?
Extremely concise (5 words) but lacks essential information. Minimalism is acceptable only to a point; here it sacrifices clarity.
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 or annotations; description does not clarify what 'resources' includes or the response structure. Incomplete for a tool with a single parameter and no additional context.
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 covers 100% of parameter descriptions (deploymentId described as 'The id of the deployment'), so baseline is 3. Description adds no additional value beyond 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?
Description restates the tool name ('Get resources of a deployment') without specifying what 'resources' entails or distinguishing from sibling tools like getDeployments or getActivityInstances. This is a tautology providing no additional clarity.
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 (e.g., getDeployments for deployment list) or any context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of deployments
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by deployment id. | |
| name | No | Filter by deployment name. | |
| nameLike | No | Filter by deployment name that the parameter is a substring of. | |
| source | No | Filter by deployment source. | |
| firstResult | No | Pagination of results. Specifies the index of the first result to return. | |
| maxResults | No | Pagination of results. Specifies the maximum number of results to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility for behavioral clarity. It only says 'Get a list', failing to disclose that the operation is read-only, supports pagination via firstResult and maxResults, or that filtering is possible. This leaves the agent with minimal expectations.
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 with one short sentence, no filler. However, it may be too minimalistic, failing to convey important operational details while remaining 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 6 parameters and no output schema, the description is incomplete. It does not clarify the response format (likely a list of deployments), default pagination behavior, or any ordering. The tool's purpose is stated but lacks depth for effective use.
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 already documents all parameter purposes. The description adds no new meaning beyond what is in the schema, earning the baseline score.
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 retrieves a list of deployments, which distinguishes it from sibling tools that focus on specific processes or tasks. However, it lacks specificity about whether it returns all deployments or supports criteria, making it slightly vague.
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 like getDeploymentResources or other list operations. The description does not mention prerequisites, suitable scenarios, or when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get incidents (errors) in processes
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | No | Filter by process instance id. | |
| incidentType | No | Filter by incident type. | |
| maxResults | No | Maximum number of results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'get incidents', which implies a read-only operation, but does not explicitly confirm non-destructiveness or mention any side effects. The description is adequate but minimal.
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, short sentence: 'Get incidents (errors) in processes'. It is concise and front-loaded with the key 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?
For a simple read tool with full schema coverage and no output schema, the description is minimally adequate. However, it lacks context about the type of incidents, relationships to process instances, or expected usage patterns.
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?
All three parameters are fully described in the input schema with 100% coverage. The description does not add any additional meaning or constraints beyond what the schema already provides. Baseline score 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 tool 'get incidents (errors) in processes', which uses a specific verb 'get' and a resource 'incidents' related to processes. It does not differentiate from sibling tools like 'getActivityInstances' or 'getProcessInstances', but the purpose is unambiguous.
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. For example, it doesn't explain when to use 'getIncidents' instead of 'getProcessInstances' or other read tools. The description lacks context about filtering or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of process definitions
| Name | Required | Description | Default |
|---|---|---|---|
| latestVersionOnly | No | Only include those process definitions that are latest versions | |
| firstResult | No | Pagination of results. Specifies the index of the first result to return. | |
| maxResults | No | Pagination of results. Specifies the maximum number of results to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It mentions only the basic action, omitting details about authentication requirements, rate limits, side effects, pagination behavior, or any constraints beyond the input schema.
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 extraneous information. Every word serves a purpose, and it is front-loaded with the core action.
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 explain return values or behavior. It lacks details about the result format, pagination limits, sorting, or what a process definition includes, leaving the agent with incomplete information.
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 all three parameters, providing clear semantics. The description adds no extra meaning beyond what the schema already conveys, resulting in a baseline score of 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 clearly states the verb 'Get' and the resource 'list of process definitions', making the purpose apparent. However, it does not differentiate from sibling tools like getProcessInstances or getDeployments, missing an opportunity to clarify scope.
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. The description lacks context about typical use cases, prerequisites, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of process instances
| Name | Required | Description | Default |
|---|---|---|---|
| processDefinitionId | No | Filter by the process definition the instances run on. | |
| processDefinitionKey | No | Filter by the key of the process definition the instances run on. | |
| businessKey | No | Filter by process instance business key. | |
| firstResult | No | Pagination of results. Specifies the index of the first result to return. | |
| maxResults | No | Pagination of results. Specifies the maximum number of results to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination (though parameters exist), or any performance implications. The description adds minimal behavioral 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 very concise (single sentence) and front-loaded with the core purpose. There is no extraneous information, but it may be too terse for complex tool understanding.
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 5 parameters, no output schema, and no annotations, the description fails to provide sufficient context. It does not explain the return format, pagination behavior, or how filters interact, leaving gaps for the 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 provides descriptions for all 5 parameters (100% coverage), so the description does not add meaning beyond what the schema already offers. 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 clearly states the verb 'Get' and resource 'list of process instances', which is distinct from sibling tools like getProcessDefinitions or getTasks. However, it lacks specificity about the scope or filters available.
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 getActivityInstances or getIncidents. The description does not mention any prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get variables of a process instance
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | The id of the process instance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states a read operation but omits traits like pagination, error handling, or whether variables are all or filtered. Minimal value added beyond the name.
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 with no wasted words. It lacks structural elements like bullet points or separation of concerns, but remains 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 or annotations, the description should elaborate on return value details (e.g., format, scope of variables). It is too terse to be complete for a data retrieval 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?
The input schema has 100% description coverage for the single parameter, processInstanceId. The tool description adds no further meaning, so 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 'Get' and resource 'variables of a process instance', making the purpose unambiguous. However, it does not differentiate from siblings like getActivityInstances or getIncidents, so it loses a point.
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 getProcessInstances or setProcessVariables. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the start form for a process definition
| Name | Required | Description | Default |
|---|---|---|---|
| processDefinitionId | No | The id of the process definition. | |
| processDefinitionKey | No | The key of the process definition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'get', implying read-only, but does not disclose return format, side effects, or permissions. Lacks behavioral 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?
Single sentence, very concise with no fluff. Lacks structure like sections or examples, but appropriate for length.
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?
Minimal description for a tool with two optional parameters and many siblings. Missing explanation of id vs key, error conditions, and return value.
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 both parameters. Description adds no extra meaning beyond schema, meeting baseline.
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 'Get the start form for a process definition' with a specific verb and resource. It distinguishes from siblings like getTaskForm and submitStartForm.
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 vs alternatives, no mention of parameter selection logic (id vs key), and no prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the form for a task
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The id of the task. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full responsibility for behavioral disclosure. It only states 'Get the form for a task' without mentioning read-only nature, permissions, side effects, or what the returned form contains. This minimal disclosure is insufficient for safe invocation.
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 front-loaded with the action, making it easy to scan. Every word earns its place, achieving perfect 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 absence of an output schema and annotations, the description should provide more context about the return value, error conditions, or behavior. It is not complete enough for an agent to reliably use the tool, as it lacks information on what constitutes a 'form' or any side effects.
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 a clear description for 'taskId'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate given the high coverage.
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 the form for a task' uses a specific verb (Get) and identifies the resource (form for a task), making the purpose clear. It distinguishes from siblings like 'getStartForm' and 'submitTaskForm' through the context of task vs. start form, though the description itself does not explicitly differentiate.
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. The description does not mention prerequisites, context, or scenarios where this tool is appropriate, leaving the agent to infer from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of tasks
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | No | Filter by process instance id. | |
| taskDefinitionKey | No | Filter by key of the task. | |
| assignee | No | Filter by assignee. | |
| firstResult | No | Pagination of results. Specifies the index of the first result to return. | |
| maxResults | No | Pagination of results. Specifies the maximum number of results to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits (e.g., pagination behavior, permissions, or side effects). The schema includes pagination params but the description does not mention them.
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 (one sentence) but under-specified. It states the basic purpose without earning its space with additional useful 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?
Given the tool has 5 parameters and no output schema, the description does not explain the return format, pagination details, or how it fits with sibling tools. It is incomplete for an AI 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?
All 5 parameters have descriptions in the input schema (100% coverage), so the description does not need to add detail. However, it adds no value 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 'Get a list of tasks' clearly states the verb and resource. However, it does not distinguish this tool from sibling tools like getTaskForm or completeTask, which also involve tasks.
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 getActivityInstances or getProcessInstances. 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.
Set/update variables of a process instance
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | The id of the process instance. | |
| variables | Yes | The variables to set/update. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. While it indicates mutation ('set/update'), it does not specify whether variables can be set after process completion, what permissions are required, or whether the operation overwrites or merges existing variables. 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 short sentence, front-loading the core action. It contains no extraneous information, achieving maximal 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?
With no output schema and no annotations, the description covers the purpose and parameters minimally. For a simple mutation tool, it might be sufficient, but it lacks details on behavior (e.g., merge vs overwrite, error conditions) that would improve 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 provides 100% parameter descriptions, so the description adds little extra meaning beyond restating 'variables' as 'The variables to set/update'. No additional constraints or format details are given. 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 'Set/update variables of a process instance' uses a specific verb (set/update) and clearly identifies the resource (variables of a process instance). It distinguishes this tool from sibling tools like 'getProcessVariables' (read) and 'deleteProcessInstance' (delete).
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 gives no explicit guidance on when to use this tool versus alternatives (e.g., when to use 'setProcessVariables' vs 'startProcessInstance' or 'completeTask'). Usage is implied by the name and description, but no exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new process instance
| Name | Required | Description | Default |
|---|---|---|---|
| processDefinitionId | Yes | The id of the process definition to start a new process instance for. | |
| processDefinitionKey | No | The key of the process definition to start a new process instance for. | |
| variables | No | A JSON object containing variable key-value pairs. | |
| businessKey | No | The business key the process instance is to be initialized with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'start', which implies creation, but fails to mention side effects, permissions, error cases, or response format. 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 with no unnecessary words. It conveys the basic purpose efficiently, though it could be slightly more informative.
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 description lacks information about return values, behavioral outcomes, and how it relates to other process-related tools. Given the complexity (4 parameters, no output schema), the description 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?
Input schema coverage is 100%, so the schema already describes parameters. The description adds no extra meaning beyond what is in the schema, meeting the baseline but not exceeding it.
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 'Start' and the resource 'process instance'. However, it does not differentiate from sibling tools like submitStartForm or activateProcessInstance, which may also involve starting processes.
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 (e.g., submitStartForm). There is no mention of prerequisites, context, or 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.
Submit a start form and start process instance
| Name | Required | Description | Default |
|---|---|---|---|
| processDefinitionId | No | The id of the process definition. | |
| processDefinitionKey | No | The key of the process definition. | |
| variables | No | The form variables to submit. | |
| businessKey | No | The business key for the process instance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action without mentioning side effects, required permissions, error handling, or that it is a write operation. Critical behavioral details are missing.
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 at one sentence with no redundant words. It is front-loaded but could be slightly more informative without lengthening it much.
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 4 parameters, nested objects, and no output schema, the description is too sparse. It lacks information about the return value, success/failure behavior, and when this tool is appropriate compared to alternatives.
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 each parameter having a descriptive label. The tool description adds no additional meaning beyond the schema, so it earns the baseline of 3. However, it does not explain how variables correspond to the start form fields.
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 'Submit' and the resources 'start form' and 'process instance', making the basic purpose understandable. However, it does not distinguish it from the sibling tool 'startProcessInstance', which may also start a process instance.
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 like 'startProcessInstance' or 'submitTaskForm'. There is no mention of prerequisites, such as the need to first retrieve the start form using 'getStartForm'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a task form
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The id of the task. | |
| variables | Yes | The form variables to submit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only repeats the tool's name without explaining side effects, idempotency, or what happens upon submission. The agent receives no safety or behavioral 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 very concise at one sentence, but it sacrifices informativeness. It is front-loaded but lacks essential details, making it minimally adequate.
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 two parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the tool's role in the workflow, return behavior, or any constraints beyond the schema.
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% for both parameters, so baseline is 3. The description adds no extra meaning beyond what the schema already provides, e.g., no clarification on the structure or expected content of the 'variables' object.
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 'Submit a task form' clearly indicates the verb and resource, but does not differentiate from sibling tools like submitStartForm or completeTask. The purpose is minimally clear but lacks 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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like getTaskForm or completeTask, nor does it specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suspend a process instance
| Name | Required | Description | Default |
|---|---|---|---|
| processInstanceId | Yes | The id of the process instance to suspend. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, reversibility, or impact on related tasks. For a mutation tool, 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?
Single sentence, no wasted words, efficient 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?
No output schema and no annotations; description lacks details on return value, effect on instance state, and prerequisites. Insufficient for a suspension action.
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 describes the parameter. Description adds no extra meaning beyond the schema, so 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 action (suspend) and the resource (process instance). It distinguishes from siblings like activateProcessInstance and deleteProcessInstance.
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 or when not to use this tool. Lacks context on prerequisites or alternatives like deleteProcessInstance.
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.0.0activateProcessInstancecompleteTaskdeleteDeploymentdeleteProcessInstancedeployBpmndeployFormgetActivityInstancesgetDeploymentResourcesgetDeploymentsgetIncidentsgetProcessDefinitionsgetProcessInstancesgetProcessVariablesgetStartFormgetTaskFormgetTaskssetProcessVariablesstartProcessInstancesubmitStartFormsubmitTaskFormsuspendProcessInstanceEach tool targets a distinct operation (e.g., deployment, process instance, task, variable, form) with clear boundaries. Overlapping purposes like startProcessInstance and submitStartForm are differentiated by direct vs. form-based start.
All tools follow a consistent verb_noun pattern in camelCase (e.g., deployBpmn, getTasks, completeTask). No mixing of styles or irregular abbreviations.
21 tools appropriately cover a BPM engine's core operations without being excessive. The count is well-scoped for the domain's complexity.
The tool surface provides CRUD operations for deployments, process instances, tasks, and variables, plus form handling and incident querying. No obvious gaps for typical lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/maksdizzy/camunda-engine-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
