# Integrating IBM Bob (AI-native IDE) with Ansible Automation Platform using MCP

**URL:** <https://forum.ansible.com/t/integrating-ibm-bob-ai-native-ide-with-ansible-automation-platform-using-mcp/45770>\
**Category:** Guides, FAQs & Howtos\
**Tags:** ai, developer, aap, howto\
**Created:** [May 5, 2026, 1:36pm UTC](https://forum.ansible.com/t/integrating-ibm-bob-ai-native-ide-with-ansible-automation-platform-using-mcp/45770 "2026-05-05T13:36:47Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![IPvSean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ipvsean/32/1153_2.png) [@IPvSean](https://forum.ansible.com/u/IPvSean)\
**Post date:** [May 5, 2026, 1:36pm UTC](https://forum.ansible.com/t/integrating-ibm-bob-ai-native-ide-with-ansible-automation-platform-using-mcp/45770/1 "2026-05-05T13:36:47Z")

</div>

As more teams experiment with AI-assisted development, one of the more interesting shifts is moving from “AI that generates code” to “AI that can safely interact with real systems.”

A pattern we’ve been working with is connecting AI tools to **Ansible Automation Platform (AAP)** through a **Model Context Protocol (MCP) server**, allowing agents to query and execute automation in a governed way.

This walkthrough from Alex Walczyk shows how to do exactly that using **IBM Bob** , an AI-native IDE:

[![](https://us1.discourse-cdn.com/ansible/original/2X/4/46f8495922bf4601a735538c52a04e444c5bbca6.jpeg "How to setup IBM Bob to work with MCP server for Ansible Automation Platform") ](https://www.youtube.com/watch?v=ZoNUCNIY1Dw)

* * *

### What’s actually happening under the hood

At a high level, IBM Bob acts as the AI interaction layer, while AAP remains the **execution and governance layer**.

The MCP server exposes structured endpoints that the AI can use, such as:

- Job template discovery
- Inventory queries
- Job execution
- Result retrieval

Instead of giving an LLM direct access to infrastructure, you’re constraining it to:

- Predefined automation (playbooks, workflows)
- RBAC controls already defined in AAP
- Auditable job execution paths

So the AI is not “doing whatever it wants” — it’s selecting and parameterizing **approved automation artifacts**.

* * *

### Why MCP is useful here

Without MCP (or a similar abstraction), integrating AI with automation typically turns into:

- Ad hoc API calls
- Custom glue code
- Limited reuse of existing automation

MCP standardizes that interaction model:

- The AI queries capabilities (what job templates exist, what inputs they take)
- It selects an action
- It executes through a controlled interface

This creates a cleaner separation:

- AI handles reasoning and interaction
- AAP handles execution, consistency, and auditability

* * *

### Example flow

A typical interaction might look like:

1. User provides intent in natural language

> “Restart the web tier in production”

1. IBM Bob (via MCP):

- Queries available job templates
- Identifies the appropriate restart workflow
- Prompts for required parameters (if needed)

1. The job is launched through AAP:

- Uses existing inventories and credentials
- Follows RBAC and approval flows (if configured)

1. Results are returned to the AI:

- Job status
- Output/logs
- Any follow-up actions

* * *

### What this is (and isn’t)

**This is:**

- A way to reuse your existing Ansible investments
- A structured interface for AI → automation interaction
- A pattern for introducing AI without bypassing governance

**This is not:**

- Letting AI generate and run arbitrary playbooks in production
- Replacing AAP’s control plane
- Removing the need for approval, RBAC, or audit trails

* * *

### Where this gets interesting

Once you have this pattern in place, you can start layering in:

- Event-driven triggers (EDA → AI → AAP workflows)
- Observability signals feeding AI reasoning
- More complex multi-step workflows coordinated by an agent

But the key point is this:  
You’re not rebuilding automation for AI, you’re **connecting AI to the automation you already trust**.