How to Setup Dynamic Bindings with Itential MCP

Overview

Dynamic bindings allow you to expose Itential Platform automation capabilities as MCP tools without writing any code. Simply configure which workflows (endpoints) or Gateway Manager services you want to expose, and the MCP server automatically creates callable tools that AI assistants can use.

Why Use Dynamic Bindings?

• Zero-code tool creation: Define tools through configuration, not code
• Reduces LLM reasoning overhead: LLM knows about the workflows/services on startup instead of having to interrogate get_workflows or get_services
• Enables use case specific agents: i.e. create an agent that can only do IPAM things or another one that only does AWS things
• Simplifies Context Engineering: Agent instructions can refer to specific tools instead of being instructed to discover workflows and reasoning through their purpose
• Schema validation: Automatically inherit input validation from Platform workflows/services
• Rapid deployment: Add new capabilities instantly by referencing existing automations
• Flexible configuration: Use INI files or environment variables
• Tag-based filtering: Control which tools are exposed to specific clients

Two Types of Bindings

1. Endpoint Bindings: Expose Itential Platform workflows as tools
2. Service Bindings: Expose Gateway Manager services (Ansible, Python, OpenTofu, etc.) as tools

Quick Start

Minimal Endpoint Configuration

[tool:provision-device]
type = endpoint
name = Provision Network Device         # Endpoint/trigger name (specific trigger)
automation = Device Management          # Automation name (parent workflow)

This creates an MCP tool that executes the “Provision Network Device” endpoint/trigger (specified in name) within the “Device Management” automation/workflow (specified in automation).

Minimal Service Configuration

[tool:run-playbook]
type = service
name = network-config-playbook
cluster = ansible-cluster

This creates an MCP tool that executes the “network-config-playbook” service in the “ansible-cluster” Gateway Manager cluster.

Endpoint Bindings (Workflows)

What Are Endpoint Bindings?

Endpoint bindings expose Itential Platform workflow triggers as callable MCP tools. When invoked, they execute the workflow with the provided input data.

Requirements

To create an endpoint binding, you need:

1. An automation in Itential Platform (found in Automation Studio)
2. A trigger within that automation with:
   • A unique name
   • A defined input schema (JSON Schema)
   • An associated workflow

Basic Configuration

[tool:my-workflow]
type = endpoint
name = Trigger Name
automation = Automation Name
description = Optional description of what this tool does
tags = optional,custom,tags

Required Fields

Important: The automation field refers to the automation name in Operations Manager, while the name field refers to the specific endpoint/trigger within that automation. For example, the automation “Device Management” might contain multiple endpoints like “Provision Network Device”, “Provision Network Device with. Options”, etc.

Optional Fields

Complete Example

[tool:provision-cisco-router]
type = endpoint
name = Provision Cisco Router
automation = Network Device Provisioning
description = Provision a new Cisco router with enterprise standard configuration including VLANs, routing protocols, and security policies
tags = provisioning,cisco,router,production

[tool:backup-config]
type = endpoint
name = Backup Device Configuration
automation = Configuration Management
description = Backup device configuration to Git repository
tags = backup,configuration,compliance

[tool:compliance-check]
type = endpoint
name = Security Compliance Check
automation = Security Compliance
description = Run security compliance checks and generate report
tags = compliance,security,audit

How It Works

1. Configuration Load: Server reads the endpoint tool configuration
2. Automation Lookup: Queries /operations-manager/automations to find the automation
3. Trigger Discovery: Queries /operations-manager/triggers to find the trigger by name
4. Schema Retrieval: Retrieves the trigger’s input schema for validation
5. Tool Registration: Registers a dynamic MCP tool
6. Execution: When invoked, calls start_workflow with the trigger’s route name

Finding Trigger Information

To find available automations and triggers in your Itential Platform:

1. Navigate to Operations Manager in the Platform UI
2. Select the Automation you want to expose (this is your automation field value)
3. Look for the Triggers section within that automation
4. Note the exact trigger/endpoint name (case-sensitive) – this is your name field value
5. The trigger’s input schema will be automatically discovered

Example: If you see automation “Device Management” containing trigger “Provision Network Device”:

• automation = Device Management (parent workflow)
• name = Provision Network Device (specific endpoint/trigger)

Or use the MCP tool: get_workflows

Service Bindings (Gateway Manager)

What Are Service Bindings?

Service bindings expose Gateway Manager services as callable MCP tools. Gateway Manager allows you to run external automation services like Ansible playbooks, Python scripts, OpenTofu plans, and more.

Requirements

To create a service binding, you need:

1. A cluster in Gateway Manager
2. A service within that cluster with:
   • A unique name
   • A service type (ansible-playbook, python-script, etc.)
   • An optional input schema (decorator)
   • The service must be enabled

Basic Configurations

[tool:my-workflow]
type = endpoint
name = Trigger Name
automation = Automation Name
description = Optional description of what this tool does
tags = optional,custom,tags

Required Fields

Optional Fields

Complete Example

[tool:deploy-config]
type = service
name = network-config-playbook
cluster = ansible-cluster
description = Deploy network configuration across multiple devices using Ansible playbooks with validation and rollback capabilities
tags = ansible,deployment,configuration,production

[tool:backup-script]
type = service
name = device-backup-script
cluster = python-cluster
description = Execute Python script to backup device configurations to S3
tags = backup,python,aws,s3

[tool:opentofu-plan]
type = service
name = network-infrastructure-plan
cluster = opentofu-cluster
description = Generate OpenTofu plan for network infrastructure changes
tags = iac,opentofu,terraform,planning

Service Types

How It Works

1. Configuration Load: Server reads the service tool configuration
2. Service Lookup: Queries Gateway Manager to find the service
3. Metadata Retrieval: Gets service metadata including input schema (decorator)
4. Tool Registration: Registers a dynamic MCP tool with FastMCP
5. Execution: When invoked, calls run_service with the service name and cluster

Finding Service Information

To find available services in your Gateway Manager:

1. Navigate to Gateway Manager in the Platform UI
2. Select a Cluster
3. View the Services section
4. Note the exact service name (case-sensitive)
5. The service’s input schema (if defined) will be automatically discovered

Or use the MCP tool: get_services

Configuration Methods

Method 1: Configuration Files – Recommended

Create a configuration file:

## Platform configuration ommitted for brevity

# Endpoint bindings
[tool:provision-device]
type = endpoint
name = Provision Network Device
automation = Device Management
description = Provision new network devices
tags = provisioning,network

[tool:compliance-check]
type = endpoint
name = Security Compliance Check
automation = Compliance Automation
tags = compliance,security

# Service bindings
[tool:ansible-deploy]
type = service
name = network-config-playbook
cluster = ansible-cluster
description = Deploy network configurations
tags = ansible,deployment

Method 2: Environment Variables

Environment variables follow the pattern:

Endpoint Example

# Define endpoint tool via environment variables
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_TYPE=endpoint
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_NAME="Provision Network Device"
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_AUTOMATION="Device Management"
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_DESCRIPTION="Provision new network devices"
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_TAGS="provisioning,network,device"

Service Example

# Define service tool via environment variables
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_TYPE=service
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_NAME="network-config-playbook"
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_AUTOMATION="ansible-cluster"
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_DESCRIPTION="Deploy network configurations"
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_TAGS="ansible,deployment,production"

Method 3: Hybrid Approach

Combine both methods – environment variables override file settings:

config.ini:

[tool:provision-device]
type = endpoint
name = Provision Network Device
automation = Device Management
description = Basic provisioning
tags = provisioning

Environment override:

export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_DESCRIPTION="Enhanced provisioning with validation"
export ITENTIAL_MCP_TOOL_PROVISION_DEVICE_TAGS="provisioning,network,validated,production"

Result: The tool uses file config with overridden description and tags from environment.

Tagging and Filtering

Automatic Tags

Every dynamically bound tool automatically receives these tags:

1. bindings: All bound tools get this tag
2. Tool name: The configured tool name becomes a tag
3. Custom tags: Any tags you specify in configuration

Tag Examples

Endpoint Tool Tags

[tool:provision-device]
type = endpoint
name = Provision Network Device
automation = Device Management
tags = provisioning,network,cisco

Automatically gets tags:

• bindings (automatic)
• provision-device (automatic from tool name)
• Provision Network Device (automatic from trigger name)
• provisioning (custom)
• network (custom)
• cisco (custom)

Service Tool Tags

[tool:ansible-deploy]
type = service
name = network-config-playbook
cluster = ansible-cluster
tags = ansible,deployment,production

Automatically gets tags:

• bindings (automatic)
• ansible-deploy (automatic from tool name)
• network-config-playbook (automatic from service name)
• ansible (custom)
• deployment (custom)
• production (custom)

Troubleshooting

Common Issues

1. Tool Not Found Errors

Endpoint Error – Automation Not Found:

Error: automation 'Device Management' could not be found

Solutions:

• Verify the automation name (parent workflow) is exact (case-sensitive)
• Check the automation exists in Automation Studio → Operations Manager
• Ensure the automation field matches the parent workflow name, not the endpoint/trigger name
• Ensure user has permissions to view the automation

Service Error:

Error: service 'network-config' could not be found

Solutions:

• Verify service name is exact (case-sensitive)
• Check service exists in Gateway Manager
• Verify cluster name is correct
• Ensure service is enabled

2. Endpoint/Trigger Not Found

Error: trigger 'Provision Device' could not be found in automation 'Device Management'

Solutions:

• Verify the endpoint/trigger name (the name field) matches exactly (case-sensitive)
• Confirm the endpoint exists within the specified automation (parent workflow)
• Check that you’re looking in the correct automation – the endpoint must be within the automation specified in the automation field
• Ensure the endpoint/trigger has an associated workflow
• Verify the endpoint/trigger is enabled

Common mistake: Using the automation name in the name field instead of the actual endpoint/trigger name.

Remember:

• automation = Parent workflow name (e.g., “Device Management”)
• name = Specific endpoint/trigger name (e.g., “Provision Network Device”)

3. Tool Not Appearing

Issue: Tool defined but not showing up in tool list

Solutions:

Check tag filtering:

[server]
# Are your tags too restrictive?
include_tags = bindings,provisioning

# Is your tool tagged correctly?
[tool:my-tool]
tags = provisioning # Must match include_tags

Check logs:

itential-mcp --config config.ini --log-level DEBUG

Look for:

INFO: Registering dynamic tool: provision-device
INFO: Tool tags: bindings,provision-device,provisioning

4. Permission Errors

Error: 403 Forbidden - Insufficient permissions

Solutions:

• Verify service account has workflow execution permission
• Check Gateway Manager service permissions
• Ensure proper RBAC roles assigned

Debugging Tools

Enable Debug Logging

[server]
log_level = DEBUG

Or:

itential-mcp --log-level DEBUG

List All Registered Tools

When server starts, check logs for:

INFO: Registering dynamic tool: provision-device
INFO: Tool tags: bindings,provision-device,Provision Network Device,provisioning,network

Best Practices Summary

Configuration

1. Use descriptive tool names: Clear, actionable names
2. Add detailed descriptions: Explain what the tool does
3. Implement consistent tagging: Follow a tag taxonomy
4. Document schemas: Include schema documentation in workflows
5. Version control configs: Track changes to binding configurations

Conclusion

Dynamic bindings provide a powerful, code-free way to expose Itential Platform automation capabilities to AI assistants and other MCP clients. By following the patterns and practices in this guide, you can rapidly deploy new tools that leverage your existing Platform workflows and Gateway Manager services.

Key Takeaways

• Endpoints expose workflows: Zero-code workflow-to-tool conversion
• Services expose Gateway services: Ansible, Python, OpenTofu, and more
• Configuration is flexible: INI files or environment variables
• Tags control visibility: Fine-grained filtering of available tools
• Schemas are automatic: Input validation inherited from Platform

Next Steps

1. Identify workflows/services to expose
2. Create minimal binding configuration
3. Test with AI assistant
4. Refine with descriptions and tags
5. Deploy to production

Bindings Documentation →

Tags Documentation →

Tools Documentation →

MCP Configuration →