Exposing AI to real systems

I noticed myself using AI way more recently. Recent large language model generations are becoming good at reasoning but they can’t reliably access systems that we already use within an environment. That made me think:

How do I let an AI system move from suggesting actions in natural language to actually interacting with the tools I already use every day?

Model Context Protocol (MCP) is an attempt to change that.

The gap between reasoning and execution

Via NVISO Security I have access to tooling & models that really start to have an impact on my productivity. One of these is the Copilot CLI from GitHub.

As someone in cyber security, I’m exposed to a lot of specialized tools and platforms every day. The question above quickly became a bottleneck. Copilot CLI is great at reasoning, but without a connection to external tools, it’s limited to generating suggestions rather than interacting with real systems.

I’m of course not the only one with this question. Anthropic proposed a solution quite some time ago in the form of the Model Context Protocol. To quote the first paragraph:

Today, we’re open-sourcing the Model Context Protocol (MCP), a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments. Its aim is to help frontier models produce better, more relevant responses.

It’s mentioned to literally connect an AI assistant, like Copilot CLI in my case, to systems and technologies I’m already using on a day-to-day basis. Let’s dive a bit deeper.

What is Model Context Protocol?

Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems. It features a specification that defines, in detail, how AI applications should use this protocol to communicate with external systems.

I think of it as a bridge between intent and actual execution. The LLM reasons what it wants to do, MCP defines how to execute that on real systems. Even though the Copilot CLI is a product from GitHub, it does not know how to talk to GitHub. Yes, the models are trained with a lot of information from GitHub, but without any additional tooling the Copilot CLI cannot communicate directly with GitHub. Enter MCP.

GitHub provides an MCP server to connect something like the Copilot CLI with the GitHub platform. This is a small server that you run locally which you have configured to be able to communicate with GitHub on your behalf. Of course, other AI agents, assistants and chatbots feature MCP support as well.

Instead of writing explicit commands, you can now just express what you want to do in natural language. This is then translated into structured API calls. The GitHub API will be addressed, which will return structured data. That structured data is then again converted to natural language and presented to you via the interface you have with Copilot CLI.

Why this matters

Without structured external tool access, LLMs tend to hallucinate or rely on guesswork when interacting with systems. This has gotten better with more recent models though. But the whole reason why APIs exist is to literally allow programmatic, non-human access to applications.

In cyber security, there’s a plethora of tools that can help people on every side of the cyber security spectrum. As I’m working in offensive cyber security, tools like Mythic (a command-and-control framework), Cobalt Strike (a widely used adversary simulation platform) and BloodHound (a tool for mapping attack paths across a network) are my bread and butter. There’s a ton of tools, frameworks and scripts that can be useful to help conduct adversary emulation exercises.

Now, take BloodHound. Imagine an LLM being able to execute queries directly against the BloodHound API through structured tool calls instead of parsing raw data in the form of json files.

In essence, MCP is a way to give LLMs controlled, structured access to tooling that is already working very well.

Example

Another example: Atlassian MCP. This MCP server acts as a bridge between an LLM and your internal Jira/Confluence stack. As I’m based in Europe, this of course starts to lean into privacy questions, but that’s out of scope for this post.

Your prompt could be:

Based on the data available in Jira & Confluence, what are the most high-impact objectives & key results I can go for this year to help our company forward?

Instead of a relatively generic response, it can now dynamically make API calls, fetch relevant info, process it, and give you a very tailored response.

This creates a bidirectional translation layer: Prompt (natural language) → structured API call → Structured data response → Tailored response (natural language).

In my world of cyber security, there are of course already examples of MCP servers, such as the BloodHound MCP server itself. These are the bridges you can run locally and give access to your internal BloodHound setups and give tailored information about attack paths in the collected data.

A snippet from BloodHound MCP. At its core, each capability you expose via MCP is just a function. You’ll notice how it maps a plain action name (admin_rights) to a specific API call:

# User info composite tool
@mcp.tool()
def user_info(
    ...
) -> str:
    """Query user data from BloodHound
    ...
    """

    handlers = {
        "info": lambda: bloodhound_api.users.get_info(user_id),
        "admin_rights": lambda: bloodhound_api.users.get_admin_rights(
            user_id, limit=limit, skip=skip
        ),
    ...

This is a tool definition. When you ask a question to an LLM having access to the BloodHound MCP server about administrator rights on machines, it will most likely detect that it needs to use this tool. In that case, the LLM will craft a structured API call, execute that, and give you a natural language response after processing the structured response again.

What’s next for me?

I personally experimented a little with FactMCP for Python in the past to quickly generate an MCP server from an existing OpenAPI specification. While this worked, it was nowhere near perfect.

I am most likely going to try other frameworks next as well. Recently I got into developing tools in Go as I really like the user experience of having single binaries that can run on multiple platforms. A quick Google search gives me mcp-go & mcp-golang. I’ll take these for a spin and see what can be built with it.

MCP feels like it’s unlocking access to let AI systems become orchestrators and analyzers of existing tooling & platforms rather than a standalone interface. Everything in this space is moving fast, but I like the direction this is going.