See how to connect a pyATS MCP server through a local Itential Gateway and use Itential Builder Skills in Claude Code to create, test, and govern two reusable network health agents.
From a natural-language request and a few environment details, the Builder Skill installs the MCP server in Docker, connects it to the gateway, registers it with the Itential Platform, creates a new network testing project, and begins building two FlowAgents: one for interface health and another for overall device health.
The process validates each layer as it goes. It checks the MCP connection, tests the exposed tools, corrects agent schemas, runs live sessions against a Cisco DevNet sandbox device, and confirms that both agents return usable health reports. Each agent is restricted by RBAC and receives only the read-only tools required for its task.
John Capobianco • 00:00
Hey everyone, my name is John Capobianco, and today I’m going to be connecting my revised PyATS MCP server and using my PyATS skill inside of the Itential platform. So this is going to be all driven with cloud code and our builder skill, as well as my IAG CTL, my local client, for my gateway that’s local, but the platform’s in the cloud. All right, so let’s try this out. And nothing is pre-staged here. This is truly a test. And let me hide this. All right, so this is the PyATS skill, and it has a nice structure in that there is a parent skill file.
John Capobianco • 00:53
All right, some core concepts and some references and some universal principles. And then in this, there’s references, and there’s all these individual, let’s say, learn, genie learn as an individual sub-skill, if you want to think of it that way, or the actual things that make up this overall skill. Now, the MCP server has been rewritten from scratch to use the latest and greatest, meaning stdio is gone, and it is a streamable HTTP that is also stateless. So, you know, a little bit more here. I’ve rewritten the README. We have all the different tools and how to plug it in. Really good little repository here, an MCP server for PyATS.
John Capobianco • 01:39
So I’d like to build a PyTS agent or two. And in my repo, I have an example.env file, which I’ve made just for one sandbox device. And I’m going to log in, IEGCTL, login, admin. Just so that when I launch my cloud code, it has access to an already logged in for this gateway. You can see I’ve got the Catalyst Center MCP running as a container, and I can use those tools in Itential. That’s right, Itential Flow AI agents can talk to Catalyst Center very easily that way. So let’s show you: if I do/Itential , there is Builder and right, there’s Builder Agent Project to spec, Flow AI agent to spec.
John Capobianco • 02:31
There’s a few different options here. I am going to use the Flow Agent and I’m going to say using the skills from this repo and let’s get the skills repo. Let’s get the root of it. Sorry here. And can you also install PyTS MCP? Here is the reference. Onto the gateway.
John Capobianco • 03:22
So the agent has access to real tools. Use the skill to make the agent use claud sonnet 5 or 4.x restrict access to the solutions engineering groups for our back. All right. So it successfully loaded this skill. We’re going to follow along as best we can here. It’s grabbing some information about the MCP. It’s looking at the ENV to make the testbed.yaml file, I think, or to replicate the ENV maybe on the gateway.
John Capobianco • 04:36
I should have maybe mentioned you have access to IGCTL, but it’ll figure that out. Maybe I will mention that. You have access to IGCTL. I’m logged in as admin. Right, and a local gateway running in Docker. Maybe give it a little bit more context. It doesn’t know that.
John Capobianco • 05:26
Yeah, this confirms IG has native MCP support. Let me check the add syntax. Right now, local gateway running in Docker. So it’s just going to grab some syntactical information, right, how to use that command line, and go ahead and hopefully set up the MCP server. And then use the skill reference and the MCPs that are now exposed to the platform to assemble some flowing I agents. And I guess I should specify, right, I would like an agent that tests interfaces device information is in the.env to make the testbed. Let’s start with an interface health and overall health agents.
John Capobianco • 06:28
Right, as we go, we’ll give it more information. So, it’s grepping the skills, and here we go, right? To create the Flow AI agent, I need the agent platform API key directly. Oh, I see, I should have that to the ENB file. Let me stop sharing my screen for a 2nd . And hi, I’m just going to go grab that ENB information that it requires. I totally forgot I didn’t set up the platform for this folder, which isn’t a big deal.
John Capobianco • 07:14
I just have to go into a different folder and grab some ENB information. This will just take a 2nd . Alright now let me start sharing my screen again everyone and let me tell it without clicking anything here here we go I’ve updated the ENV apologies sorry I forgot I was in the PyTS MCP folder not a different working directory that had an ENV file I should have set that up ahead of time but it picked it up and it asked me for it so it’s not a big deal now I can see that it’s looking through the skills right content skills PyTS references it’s looking through some different files here in the repo and now it has access to the platform and everything through the env file so it can actually create those it needs that it needs that information to build their skill So here we go. Let me create the testbed file, update.env, and kick off the Docker build in the background since PyETS full install will take a while, and it will. So it’s, yeah, this looks good. Now let’s build and launch the PyETS MCP server container, right?
John Capobianco • 09:02
So running it in the background. So we can keep an eye here for a new container with PyETS inside of it as an MCP server since it’s HTTP streamable. All right, here we go. Project ID. Oh, I see. Should these go in the Cisco Catalyst Center? Right, so no, we’re going to do a new project, PyTS network testing.
John Capobianco • 10:09
And we’re going to give it to these RBAC groups. Very good, very good. And we’re going to submit those answers. And let’s just keep an eye. Is the Docker up yet? Not yet. We’re going to keep an eye on that.
John Capobianco • 10:26
So, where do you want to put these agents? Kind of came back to me, and who should have access to them? So, background command completed. So, it built the PyTS Docker image. Now, it’s going to have to bring it up, I assume, next. So, there it is. And really cool, up and running.
John Capobianco • 10:44
And it did a test. Okay, very cool. So, MCP server is up. I bet you, if I check in the platform now, if I just start a new project, well, let me just go into an existing project and I just want to check an agent here and look for PyTS. Alright, so I want to see it coming from my that’s an existing PyTS one, so I’m going to have to go clean that out maybe so there’s no confusion or make sure I’m picking the right PyTS tool. Might not have synced with the platform yet, but yeah, I want to just see if there’s I have to edit it.
John Capobianco • 12:01
Yeah, that’s right. I thought I could filter here by, yeah, John Capo cluster. There we go, that’s what I want. All right, so I’ll keep an eye on that as the process moves along as well. Yeah, it’s still connecting it with gateway just because the PyTS server is up. So now the next step is going to be IGCTL commands to add that MCP server to the gateway. Alright, so here we are.
John Capobianco • 12:39
Re-register the gateway now that it’s actually reachable. And then I’ll see it in the platform. So just give it a couple minutes here. This is going to be a lot of fun seeing the skills in action and the MCP together one, two punch. So the skills, all right, so our PyTools are now active. Let’s confirm that they’re all active in a couple key ones. So now I think if I refresh my gateway.
John Capobianco • 13:26
And edit the agent and filter this. There we go. Now, now we’re talking, and you can see that I have all 26 tools. Device health, configure device, clean device, get neighbors, all kinds of really good stuff here. Yeah, all right, wonderful. So if I go back to my agent projects, down here at the bottom, there’s going to be a new PyDS project soon. And it’s just doing that right now.
John Capobianco • 14:11
The project now has. So let’s see, is there a new project now? Not yet. No, there it is. PyTS network testing. It’s at the bottom. Alright, so we have a project.
John Capobianco • 14:38
And now we’re going to actually get a couple of those testing agents. And it’s just doing some testing. So that’s what I love about this process as well, is that it actually validates. It’s not just going to attach these tools. It’s going to test some things as it goes. So what we get is a viable working agent. And if anything fails along the way, it will stop and interrogate us with questions or with requirements or other things, right?
John Capobianco • 15:08
So that’s a really big advantage to this approach as opposed to just maybe these MCPs don’t work. Maybe there’s a problem in the installer, the server, or whatever. So it’s actually going to run through those tests in a scratch pad. You can see it’s doing an agent interface health temporary scratch pad here. And I’m pretty sure that we’re going to have a health agent here in a 2nd . All right, here we go. Creating the PyTS interface health agent.
John Capobianco • 15:52
Note added to the instructions text since the device and the interface filter have no inline description. Okay, retrying creation of both agents. Alright, it had a that’s alright. We’re going to recreate both agents now. At any 2nd in here, I should have a couple of agents. Creating both PyTS interface health and overall health agents with fixed schemas. I see a templated device named placeholder in the instructions.
John Capobianco • 17:05
Okay. Test run. It looks like there’s a test run. Session started. Polling for completion. This will call the real DevNet sandbox, so it might take a bit. All right, so does that mean it’s in my whoops?
John Capobianco • 17:27
Here we go. Interface health agent ready to launch. Check interface administrative operational status, IP addressing, error drop, discount counters using R1. Overall health using the health snapshot. So they’re going to have different tools, I think. Okay, here we go. This is cool.
John Capobianco • 17:47
So this was all created from the skill with access to the MCP. And look, it picked three tools here. This device’s search devices run show command. That’s all it needs. And we’ve picked the Sonnet 5 model. And this whole project is restricted to the group. And then the overall health from the skill again is actually going to use a few more tools.
John Capobianco • 18:18
It’s going to use the device health tool. Right? And the run show command. Pretty cool. Now, I don’t want to click on run because I’m not sure if this is just going to stop. So let’s wait until the session is done. And let’s check our agent sessions here to make sure that.
John Capobianco • 18:43
Okay, so it’s running right now. Overall, health is running. This is awesome. All right, so five tool calls triggered by an API, which is cool, right? I can trigger this via API. Thousand tokens, we got the reasoning, and we have the tool calling. And now it looks like it’s probably towards the end of the reasoning.
John Capobianco • 19:18
A lot of input tokens because it’s the health check and we get a lot of data back. All right, all right. And there we go. So it took 2 min and 21 seconds, 4,000 output tokens. Here’s the health report. We’ve got identity, CPU, memory, interfaces, mostly healthy, OSPF, BGP, log crash indicators, overall healthy. Complete.
John Capobianco • 19:52
Really cool, right? Like, I’ve just explained it. We walked through it together. I don’t know what else to say. I’ve told it what I wanted it to do, and I gave it the two Git repositories, one for the MCP, one for the skills. I asked it to build a couple of agents, and it did. And now it’s pulling the final answer.
John Capobianco • 20:18
So let’s go ahead just to be, for the sake of completion here, being complete, let’s run the interface health agent and we’ll watch it together. And this is the name of the device. So this is R1. Run. So this is universal. What device you want to check the interface is health. Run R1 or whatever, core, distribution, data center.
John Capobianco • 20:46
Just type in the one you want to check and it will go ahead and test the interfaces. You can see that we’re running learn, right, interface feature learn. Now I added learn and it’s also running a couple of show commands, not just learn. All right, and the reasoning here. And once the tools are done, we’re going to get more reasoning. So, tool calls are succeeded. Learn takes a little bit more time, obviously, than running a couple of little show commands.
John Capobianco • 21:26
Let’s check back in on our build harness here. Overall, health produce. A genuine detailed health report on a real Cisco device following the exact health check discipline baked into its instructions. It’s going to quickly test the interface health agent too. Well, I’m running it right now, so it’s going to run twice. Really excited about this. I have such an affinity for PyETS.
John Capobianco • 21:58
I mean, I keep the book here by my desk, and in fact, a lot of these enhancements to the version 2 of the PiETS MCP, if you want to think of it that way. There we go. So, there’s the interface health report, minute 35 seconds. Just type in the device you want to check for health. So, we have some interfaces of note, all the anomalies. And the down interfaces that are bulk down. Overall, healthy with one degraded item.
John Capobianco • 22:40
VLAN 20 has an IP, but the SVI is up or down, so that subnet’s unreachable. I mean, how awesome is that? How great is that? So, back to me. That was it. I don’t know how long we’ve been recording for now. Is there a timer on my screen somewhere?
John Capobianco • 23:00
Probably not. From nothing but a local gateway and the IEG control, which I logged into, go into cloud code with the itential builder skills. Point the builder skill at the skill repo for PyTS in this case and the MCP repo. It 1st set up the MCP on my Docker as a container and then wired it into the gateway, which then presented it in the platform. It then used the skills to build two flow AI agents that each run in under two and a half minutes for health of interfaces and overall health. When you run it, it takes in a parameter. You watched me do it.
John Capobianco • 23:49
Okay, anyone can do this. We’re going to democratize access to information. So thank you, and I hope you found this interesting. There’s my timer. 23 minutes with 5 min of me blabbering on and some latency in things running because it’s PyTS over SSH. So, right 10-15 minutes, start to finish, two valuable health agents that I could use in production that are only read-only, that only have access to very limited scope tools, and that could help you determine the health of your network. Thanks for joining me on this little quick vibe.
John Capobianco • 24:25
Thanks.
See how Itential connects AI reasoning to governed execution across your entire infrastructure.