--- title: "Understanding MCP: Connecting AI to the Tools We Already Use — Thoughtful Robots" description: "MCP has quickly become part of the vocabulary around AI. As it becomes more common, it is worth revisiting the basics: what it is, how it works, and what it means for the software we use or build." source: "https://thoughtfulrobots.ai/articles/understanding-mcp-connecting-ai-to-the-tools-we-already-use" --- # Understanding MCP: *connecting AI to the tools we already use* MCP has quickly become part of the vocabulary around AI. As it becomes more common, it is worth revisiting the basics: what it is, how it works, and what it means for the software we use or build. MCP has quickly become part of the vocabulary around AI. Most of us have probably heard about MCP servers, tools and connecting AI to applications. But as MCP becomes more common, it is worth revisiting the basics: **What exactly is MCP? What are hosts, clients and servers? What is the difference between tools, resources and prompts? How does MCP relate to APIs? And what does it actually mean for the software we use — or build — in an organisation?** This article is a simple refresher on those concepts, using a few practical examples to connect them together. ## Why Does MCP Matter? Most organisations already use many different software systems to get work done. A sales team might work with a CRM, email, calendars and documents. A finance team might use an ERP system and spreadsheets. A software team might work across Jira, Confluence, Figma, GitHub and testing systems. Traditionally, **people use the interface**, while **software uses APIs and integrations**. AI introduces another participant. It may need to retrieve information from these systems, understand what capabilities are available and, where permitted, take actions on behalf of a user. For example, we might ask an AI assistant: > “Look at the customer issues reported this month, identify which ones relate to features currently being developed, and tell me which ones could affect our next release.” Answering that could require information from a support system, Jira, product documentation and perhaps the code repository. As the number of AI applications and business systems grows, building a different integration for every combination becomes difficult. **MCP provides a standard way for AI applications and external software to make these connections.** ## What Is MCP and How Does It Work? **MCP stands for Model Context Protocol.** It is an open standard that provides a common way for AI applications to connect to external software and systems. Instead of every AI application needing a completely different way to understand and interact with every system, MCP defines a common way for those systems to expose selected capabilities. At a high level, an MCP connection has three parts: **Host → Client → Server.** The **host** is the AI application or environment where you are working. The **MCP client** manages the connection. The **MCP server** makes selected information and capabilities of another system available. Conceptually, we can think of it as: **You → AI application → MCP → External software** For example, a project-management system might allow an AI application to find a project, retrieve its open tasks or create a new task. The project-management system still owns its data, business logic and permissions. **MCP provides a common way for the AI application to discover and use the capabilities that have been made available to it.** ## What Can Software Expose Through MCP? This becomes particularly interesting when we look at MCP from the other direction: **what if we own the software and want AI applications to interact with it?** We do not necessarily need to rebuild the application for AI. An MCP server can expose selected capabilities from the software, often using its existing APIs and business logic. Conceptually: **AI application → MCP server → Existing application / APIs** MCP provides three particularly useful concepts for doing this: **resources, tools and prompts.** Consider an HR system connected to an AI assistant. An employee asks: *“I'm planning to take two weeks off next month. Can you help me?”* **Resources are information to work with.** The MCP server could make the company's leave policy available as a resource. A useful way to think about resources is: *“What information is available for me to work with?”* **Tools are capabilities that can be used.** The HR system might expose a tool such as `get_leave_balance(employee_id)` to retrieve the employee's available leave, and another such as `submit_leave_request(start_date, end_date)` to submit a request. The first retrieves information, while the second performs an action. So a tool does not necessarily mean changing data. A useful way to think about tools is: *“What capabilities can I use?”* **Prompts are reusable instructions.** HR might provide a prompt called `plan_extended_leave`. It could instruct the AI to consider the employee's leave balance, company policy, public holidays and required approvals when helping them plan their leave. The prompt does not contain the leave balance or submit the request. It provides a reusable way of approaching the task. Think of prompts as: *“What predefined ways of working are available?”* So, for one request, the AI could use the leave policy as a **resource**, check the employee's leave balance using a **tool**, use a **prompt** to help plan the extended leave, and finally use another **tool** to submit the request. A useful mental model is therefore: **resources provide context, tools provide capabilities, and prompts provide reusable instructions.** An MCP interface should expose **what is useful, rather than everything the underlying software can do**. The important questions are what information the AI needs, what actions it should be able to perform, and what should remain restricted or require human approval. ## MCP Does Not Replace APIs MCP does not replace APIs. In many cases, it works on top of capabilities that already exist. Suppose our HR system already has an API for retrieving an employee's leave balance. An MCP server could expose a `get_leave_balance` tool while using that existing API behind the scenes. Conceptually: **AI application → MCP server → Existing API → Application** The API continues doing the underlying work. MCP provides a standard AI-facing way to discover and use that capability. So organisations do not necessarily need to rebuild existing systems for MCP. It can provide an additional AI-facing layer over the APIs and business logic they already have. ## MCP in Software Development: Before and Now Software development provides a useful example of why this matters. Consider a team building a new **refund feature**. Traditionally, the requirement might be tracked in Jira, detailed documentation in Confluence, the design in Figma and the code in GitHub. A developer moves between these systems — reading the Jira issue, finding the relevant documentation, checking the design, working with the code and reviewing test results. APIs and integrations already automate many predefined hand-offs, but **the developer is often the person bringing the context together.** Now imagine the developer tells an AI assistant: *“Help me implement the refund feature. Understand the requirement, check the latest design, follow our engineering standards and tell me if anything is unresolved.”* The underlying systems don't disappear. **Jira remains Jira. Confluence remains Confluence. Figma remains Figma. GitHub remains GitHub.** What changes is how the developer can work across them. Instead of thinking primarily in terms of: **Human → Jira / Confluence / Figma / GitHub / Testing** we increasingly have the possibility of: **Human → AI environment → Connected systems** MCP can provide a common way for those systems to make selected information and capabilities available to the AI environment. It does not mean every system or interaction needs to use MCP. APIs, direct integrations and existing interfaces continue to matter. ## What Should Businesses Do About MCP? The software-development example is just one illustration. The same idea can apply to sales teams working across CRM, email and documents, support teams working across ticketing systems and knowledge bases, or finance teams working across ERP systems, reporting tools and spreadsheets. But the starting question should not be *“Where can we use MCP?”* Start with the work. Ask what the person is trying to accomplish, what information the AI would need, what actions would be useful, where those capabilities already exist, and what the AI should be allowed to access or change. Then ask whether MCP is an appropriate way to connect them. For software you already use, this may mean understanding what MCP capabilities are available. For software you own, it may mean exposing a small number of useful capabilities through an MCP server. **MCP is the connection mechanism. The more important decision is what we want AI to be able to access and do.** ## How We Think About This at Thoughtful Robots At Thoughtful Robots, we are interested in MCP for a simple reason: **AI becomes more useful when it can work with the systems, information and tools that people already use.** But the starting point should not be the protocol. It should be the work. We look at what people are trying to accomplish, what context AI needs, what actions would genuinely help, and what should remain under human control. MCP, connectors, APIs and other integration mechanisms then become ways of making that experience possible. **The goal is not to add MCP everywhere. It is to make AI a useful part of how the organisation already works.** **Exploring where MCP could fit in your organisation or product? We’d be happy to work through it with you.** Explore our workshop: [https://thoughtfulrobots.ai/workshop](https://thoughtfulrobots.ai/workshop) Figuring out where AI belongs — in your product or how your organisation works? **Let’s work through it together.** ### We added WebMCP to our website. *Here's what we learned.* What WebMCP is, the three browser tools we built on our own website, where they added value and where they did not, and why we treat it as progressive enhancement.