Why should I care about MCP Servers and Tools? – Part 1

[Forrest Falk]

I'm Forrest Falk, a ServiceNow Certified Master Architect (CMA). In this post, I'll share practical insights from a CMA's perspective on what an MCP Server is and what its tools do. This is part of a series, so I'll be posting updates as I go. In each post, I'll share my experience with these tools and how I think about them.

What is an MCP Server?

ServiceNow defines an MCP Server as:

The Model Context Protocol defines a standard method of communication between large language models (LLMs) and external systems, such as a ServiceNow instance. AI applications connect to an external system from an MCP client, such as an AI agent, using an MCP server. The server tells the client which external resources it can access and how to access them. Then, from an MCP client, users can request information from the server and automate functionality using the available tools and data that the server returns. For general information about the Model Context Protocol and MCP terminology, see the Model Context Protocol documentation on the modelcontextprotocol.io website.

So it allows AI agents to connect to external systems—but what can it actually do?

"What does the MCP Server actually do?" is a question we get a lot. The MCP Server's job is to tell the AI agents calling it which tools are available. For example, say you create an Incident MCP Server so that any AI agent can call it on your ServiceNow instance. Within that Incident MCP Server, we provide a list of tools. Let's say we want an incident lookup to easily search for and retrieve incident details. We also want a "create incident" feature so the AI agent can create incidents for issues it finds in another system. And we want a "close my incident" feature so we can close incidents I created once they're no longer needed. We could add more incident tools, but let's stick with those three for now.

When the AI agent calls our Incident MCP Server in ServiceNow, it receives the list of those tools (Find an Incident, Create an Incident, Close My Incident) along with the requirements for each one (incident number, tool name, etc.). Based on this catalog of tools that the MCP Server returns, the AI agent can make an informed decision about what to do next.

We've answered how it works, but we still need to cover why you'd use an MCP Server. Let's look at the alternative for manipulating incidents from an external system: the REST Table APIs. If I wanted to use the REST Table APIs in ServiceNow to perform those same functions, I'd first have to find the endpoints to create and update incidents. I'd also need to find the required data, such as table names and the sys_ids of the records I want to update. Then I'd have to determine whether all the data I need is on the Incident table, or whether I need to pull from other tables to return it.

As you can see, the REST Table API approach adds a lot of extra steps and data requirements, because my AI agent has to research those REST endpoints and build a plan to execute them, rather than simply being handed straightforward tools that can run deep and complicated workflows and handle the complex technical details for it. Overall, this speeds up the AI agent's processing time and reduces the amount of context it has to carry, which lowers costs.

Next time, let's start to dig into the different tools we can offer with the MCP Server. 

Sources:

Link to Exploring the MCP Server Console: https://www.servicenow.com/docs/r/zurich/intelligent-experiences/enable-ai-experiences/exploring-mcp...

Part 2: Coming Soon!