MCP, APIs, or Excel files? How to connect AI to your data

When I hear that connecting a new tool is all it takes for AI to work with company data, I think about the report someone will have to discuss in a meeting. A clear answer or a convincing chart is not enough for me. I want to know where the information came from, how recent it is, and what happened between the question and the conclusion. A connection may save us an export; it may also make a step less visible that we used to check ourselves.

For this reason I would not start from the choice between files, API and MCP as if they were three competing products. I would start from work. Do I have to analyze an already closed situation, always produce the same report or interrogate different systems while I think? They are similar needs, but require different controls. And before adding a gateway I would like to understand who will use the tools, with what permissions and with what responsibility for the result. In this guide I follow the same example through the different possibilities: a marketing team that has to read campaigns and commercial contacts. It is a teaching case, not the story of a client or a test performed.

Before connecting: What outcome should the team produce?

Imagine a marketing manager who needs to understand whether campaigns are generating useful inquiries. Advertising platforms show spending and conversions; the CRM, which manages customer relationships, holds contacts, deal stages, and the sales team's assessments. The manager wants a report that relates this information and identifies what to investigate. They do not yet want to change budgets or pause ads. The initial scope is therefore reading and analysis.

The difficulty does not begin with the protocol. Start with the meaning of the columns. A platform conversion could be the sending of a form, while the salesperson only considers a request with certain characteristics qualified. If the AI ​​finds two different numbers, it cannot decide on its own that one of them is wrong. They could describe different moments of the same journey. Before adding or comparing them, a shared definition is needed.

The connection between the records must also be demonstrated. Seeing a campaign in one system and a contact in the other does not mean you know that that contact comes from that campaign. An identifier, an attribution rule or another documented reconstruction may be needed. If they are missing, the correct outcome is to declare the limit. No connector transforms a possible relationship into an observed fact.

I would then write the expected outcome before choosing the technology: a summary with period, account, currency, metric definitions, data source, extraction date, missing information and issues to check. The report must allow another person to redo the route. This requirement remains identical whether we deliver an Excel sheet or query an MCP server.

Three ways of getting to data, not three stages of maturity

Manual file, API and MCP integration answer different questions. The first mainly concerns the delivery of material. The second concerns the interaction between programs. MCP is about a shared way of presenting context and capabilities to AI applications. In a real process they can coexist: a part of the data comes from an API, a document is loaded by hand and a server makes a function available through MCP.

The distinction matters because it avoids an expense built on the label. An already stable integration does not need to be replaced to appear more up-to-date. And an initial analysis does not necessarily have to become an infrastructure project. The useful question is which step we want to make more reliable, repeatable or accessible, knowing that each new link also requires maintenance.

Manual files: a controllable copy, with an expiration date

In the simplest path, one person exports the campaign data and another prepares the CRM material. Before uploading them to the assistant, check that the period is the required one, that the accounts are relevant and that there are no unnecessary personal fields. The file should not arrive alone: ​​it must be accompanied by an explanation of what it contains, how it was obtained and what information was excluded.

Let's think about a sheet with the names of the campaigns, the spending and the conversions. A column called "results" is too ambiguous. The AI ​​can read the name, but it cannot reconstruct a definition that no one provided it. I would add a note clarifying which event is counted, which time range is included and whether there are filters. The quality of the work begins here, before the prompt.

The advantage is the possibility of delimiting the material. For an analysis of a concluded period it may be useful to keep exactly the copy on which we reasoned. If the manager asks why a conclusion was made, we can reopen that package and see what information was available. Copy stability is a useful property when we want to reconstruct a decision.

The limit is equally concrete. If the CRM is updated after export, the uploaded copy does not change. To include the update you need to extract and deliver the data again. A product may offer synchronization functions, but they must be verified as additional capabilities: they do not belong to the simple uploading of a file. “AI has the data” therefore does not mean “AI has the latest data”.

How would I prepare the work package

I would create a recognizable folder for that report. Inside I would put the authorized extracts and a legible note: source, time of extraction, period analyzed, currency, meaning of the columns, filters and known problems. I would separate the received files from subsequent transformations. If I correct a name or group categories, I want to retain the ability to understand what I changed.

I wouldn't upload more data just because space allows. To compare an expense with the quality of requests, you may not need names, emails or free texts of contacts. The loading location and service conditions must be considered before delivering company material. Manual does not automatically mean private; it means a person makes the transition.

The final check concerns reading. A file may be truncated, interpreted with the wrong separator, or have columns that contain mixed formats. Before summarizing I would ask the assistant which lines and fields he actually read and compare the totals with the source. An elegant report built on an incomplete extract remains incomplete, even when the formulas seem plausible.

API: A designed request, not automatic reasoning

An API, Application Programming Interface, is an interface that allows software to interact with another component. In our case we are mainly interested in the APIs of business services. As the MDN glossary explains, the interaction follows rules and functions made available by the software. It is not necessary to imagine it as an intelligence that understands our goal.

In the report example, a program requests account data for a set interval and receives a structured response. Another step can request contact statuses from the CRM. The integration designer must specify the necessary information, interpret the responses, and decide what to do if a request fails. The API makes the intended access possible; the process gives it a purpose.

This work can happen without a model deciding every move. If the report must always collect the same fields, apply the same rules, and produce the same report, a deterministic sequence may be appropriate. Deterministic means that the steps are defined by the process, rather than chosen every time during a conversation. The AI ​​can intervene later, to discuss the results already prepared.

It's a useful distinction for marketing. Not every repetitive activity needs a reasoning agent. Sometimes what is needed above all is reliable collection, accompanied by checks. Adding freedom of choice where the task is already known can introduce variability without clear benefit. I would use conversation where exploration or interpretation is needed, and I would make explicit the passages that must be repeated the same.

What remains to be designed when the API exists

A service can return results across multiple pages. If the integration only reads the first one, the report may appear successful despite having lost some of the data. You may also encounter request limits, expired credentials, or fields that are no longer available. These cases require expected behavior: reporting incompleteness is different from replacing a missing value with zero.

The freshness of the data also depends on the source. A response received now may contain delayed updated information. Or the program can use a temporary copy, the cache, to avoid repeated requests. The time of the call and the moment to which the data refers do not necessarily coincide. This is why I would like both in the report, when available.

Finally, someone is needed to start the work. If we want a periodic update, we need planning and management of the execution: what happens if the service does not respond, who is notified, when to try again and how to avoid producing two contradictory reports. The presence of the API alone does not create complete automation. It is a component of the project, not the entire project.

MCP: What tools can the AI application use?

MCP, Model Context Protocol, is an open protocol for exchanges between AI applications and servers that provide context and capabilities. To understand its role, return to the conversation: the marketing manager does not always need the same report. They might ask for more detail about a campaign or another way to examine inquiries. The application needs to know which tools are available and how to request their use.

In the official architecture, the host is the application that hosts the AI experience; the MCP client is the component through which it interacts with the server. The server exposes capabilities. There is no need to confuse these roles with the model: the model participates in reasoning, while the application actually manages the interaction with the tools.

Suppose a server exposes a function called leggi_report_campagne. The name is invented for this explanation and does not identify an installed connector. A useful description should indicate what it does, what parameters it requires, and what it returns. If a period and account are required, these must be specified. It should not leave implicit a choice capable of changing the meaning of the result.

The compatible application can request the execution of the tool and receive the result. Behind the server, the fetching could use the advertising platform's API. MCP and API can therefore be in the same chain. MCP organizes a way of exposing capabilities to the AI ​​application; the API can be the means used to interact with the underlying service. They are not necessarily technical alternatives.

Tools, resources and prompts: not everything is a command

The MCP specification distinguishes tools, resources, and prompts. A tool performs a function; a resource can provide context; a prompt provides a reusable template. For our report we could imagine a function that reads data and a document that explains the metrics. They are different roles, both useful for understanding an answer.

However, actual availability depends on the server and the application that uses them. The protocol does not imply that all services already have a suitable server, nor that every client supports every capability. Before designing the work I would like to see what is actually exposed, what parameters are allowed and what limits exist. A demo on one application does not automatically demonstrate the same behavior on another.

If the required field is missing, I don't consider it a problem to be solved just by rewriting the question. It may be missing in the source, API, exposed function or permissions. The assistant should make the absence visible. The natural language request does not add data that the system cannot obtain and does not authorize access that has not been granted.

In simple words: dossier, interface and common language

The file is the dossier I bring to a meeting. I have chosen the material and I can keep it, but if something changes outside the room I have to update the dossier. The API is an agreed upon interface for requesting information or operations from a system. MCP offers a common language with which an AI application can learn about and use capabilities exposed by a server.

The analogy has a limit: none of these steps certifies what is inside the dossier or the response received. A piece of data may be old, a metric may have an unexpected meaning, and a function may return less information than desired. The link is the path; the verification also concerns the content that passes through that path.

For this reason I would avoid saying that MCP "makes the model speak directly with all the software". The phrase hides application, server, permissions, and transformations. It seems to simplify, but it takes away the very pieces that a company must manage. The useful explanation instead allows you to indicate where information has been chosen, read, filtered or modified.

The comparison I would use before choosing

For an occasional analysis of a closed period I might choose the file. If I want a recurring report with stable rules, I would evaluate API integration and its scheduled execution. If I want to explore data through an AI application using available capabilities, I would evaluate MCP. The choice depends on the task; I wouldn't give an automatic award to the latest technology mentioned.

I would also consider the cost of making the change. A new connection requires configuration, knowledge of the systems, verification, and maintenance. Reducing manual work is an attractive possibility, but it needs to be weighed against these activities. This guide offers no price list or savings percentage: without measuring a defined scope of work, a precise number would only create an impression of certainty.

A practical exercise to compare the three paths

The first exercise I propose does not require connecting production accounts. It is used to define a verifiable result before building access. You can work with authorized extracts free of unnecessary personal information, or with a declared synthetic dataset. In the second case, the material is used to practice the method, not to demonstrate a commercial benefit.

Write the result and conditions before the request

The delivery of our case is this: prepare a summary of the campaigns and qualified contacts for the same period, distinguishing what is observed from what we cannot connect. The report must declare if the definitions do not coincide and what insights the manager needs. It must not change anything in the systems or suggest that an undocumented link has been demonstrated.

I would also write down the stopping conditions. If the period is missing, I do not pretend to know the correct one. If the response omits some results, I do not treat it as complete. Without a demonstrable link between campaigns and contacts, I can describe the two sources but cannot attribute sales to campaigns. These rules make the exercise useful even when the answer is, 'We cannot draw a conclusion yet.'

Work only with materials and tools authorized for this report.
Before forming conclusions, please indicate period, account, currency, metric definition, data source and time of extraction, if available.
Check which fields are present and what information is missing. Don't turn an absent value into zero.
Don't link records from different sources without an explicit key or method. State the limits of attribution.
Separate observations, hypotheses, and checks to assign to the person responsible. Show the transformations needed to reconstruct the result.
Don't change campaigns, budgets, contacts or other systems. If a necessary condition is missing, stop and explain it.

Perform material verification first

In the manual path, deliver the files along with the context note. Ask for a description of the data before interpretation: which columns were read, which categories appear and what range is present. Compare these elements with the source material. There is no need to immediately ask for a strategic comment; first you need to know if the assistant is reading the package you think you gave it.

If you find a difference, document it and correct the cause. It could be a filtered export or a poorly explained field. Just asking “check again” doesn't tell you where the process broke down. The goal of the exercise is to come away with a more precise definition of the job, not with an ever-longer prompt that covers every possible surprise.

Turn delivery into a requirement for integration

For the API path, the same worksheet becomes a specification. Whoever creates the connection must know which accounts to query, which fields to recover, how to recognize incompleteness and how to document the transformations. The result should not just be a table: it should also contain the information necessary to understand whether that table is usable.

For the MCP path I would ask to see the list of capabilities actually exposed, the parameters and an example of an allowed response. Then I would compare the material obtained with the source, without assuming that the name of the tool guarantees the desired coverage. leggi_report_campagne can be a clear name and still return a subset that doesn't fit the question. It is the function contract that we need to check.

Deliver a factsheet, not just a conclusion

The final output of the exercise includes the summary and a sheet with origin, coverage, missing fields, transformations, checks carried out and decisions still open. If another person cannot distinguish the original data from our interpretation, the delivery is not yet ready for an important choice.

This is the link with the digital strategy with ChatGPT: the quality of the questions and materials precedes the synthesis. In the workflow with ChatGPT, Claude and Gemini, distinguishing production and criticism helps to discuss a result without mistaking agreement between models for proof. The content factory with human control adds another piece: what is automated must have a manager and a real ability to review.

Reading is not editing: where would I put the boundaries

In our example, we need to read and analyze data; that does not require permission to change budgets. Separating capabilities also clarifies the assignment: proposing a correction and applying it are different actions. A process using tools that write to systems must define which actions are permitted, how they are checked, and when a human decision is required.

I would then distinguish identity from permission. Knowing which user is logged in does not mean that anything is appropriate. The account context, customer, period and action must be within the intended scope. MCP security practices also address issues related to proxies, credentials and access: the presence of an intermediary requires controls, it does not make them superfluous.

Another boundary concerns the instructions contained in the materials. An external note can try to convince the assistant to ignore the task and pass information elsewhere. It's the type of problem referred to as prompt injection. For the team, it means not treating every text read as a trusted command. The request written in the chat does not replace limited permissions and controls on the operations that can actually be performed.

When verifying the project I would also ask how a failure is recognized. An explicit error is more manageable than a report that appears complete without being. I want to know if a tool has read only part of the data, if access has expired or if a transformation has excluded records. Transparency is not a detail to be added at the end: it determines how much we can trust the delivery.

MCP gateway: when the connection becomes a management problem

So far we have been thinking about an application and the capabilities it needs. Now imagine that different teams use different applications and that each group needs to reach multiple servers. Configurations can multiply; it becomes more difficult to understand what tools are available, who has access and where to observe calls. It is at this level that I would evaluate a gateway.

An MCP gateway is an intermediary between client and server, with implementation-dependent functions. It is not a smarter model, nor a mandatory component of every MCP project. It can centralize part of the management, but it must be evaluated with respect to the concrete problem: distributing configurations, controlling access or following operations are different needs from "obtaining a better response".

The Docker Gateway Documentation describes configuration, credential and access management, routing, and server lifecycle management, with server isolation and call tracing. The same page distinguishes access conditions for functions related to AI Governance. So I wouldn't read the word gateway as a promise that every installation includes all the desired business controls.

Choice adds responsibility. Who updates the gateway? Who checks that the access policy matches the roles? What information ends up in the logs and how long is it kept? What if that midpoint isn't available? Centralized management can help, but it also concentrates some of the operational work. For a first exercise with a single server I might not need it.

The MCP frontiers: what is documented today

As checked on November 2, 2026, the official specification page marked as current points to 2026-07-28. This matters because a guide can mix documents from different periods and present changed behavior as universal. The July 28 release announcement introduces a stateless core, self-contained requests, header-based routing, and cacheable list results.

In practical terms, a request containing the information needed to handle it can make things easier for the infrastructure receiving and routing it. 'Stateless' describes the protocol: it does not mean that a CRM stops storing data or that an application forgets everything. The technical change should not become a slogan about memory disappearing. Before adopting it, check the versions and compatibility of the components you actually use.

The release also formalizes a system of extensions. This makes it even more important to distinguish documented capability and product support: finding an extension does not prove that your client and chosen server implement it. For a team the question is not just “does it exist?”, but “can we use it in this process, with these controls?”.

Tasks: follow a job that doesn't end right away

The MCP Tasks extension allows you to manage long operations through a persistent identifier and status consultations until the result. It requires explicit support from the parties involved. In the case of the report, it can be relevant when a process does not end in the first response. It is not the same as giving the system a timetable, a responsibility or an autonomous objective: these elements remain to be designed.

The operational consequence that interests me is the possibility of separating "request accepted" from "job completed". They are different events. A team should be able to recognize what is still in progress, what requires intervention, and what outcome is final. This distinction is useful even without using MCP: the extension gives a technical form to a process problem that we still need to understand.

MCP Apps: Interact with the result in the conversation

MCP Apps allow you to present interactive interfaces in compatible hosts. In our example, the perspective is to explore the data along with the conversation instead of just receiving a description. Here too we need to check support, accessible operations and interface boundaries. The presence of an interactive table does not prove that the data is complete or that the decision is correct.

My interpretation is that these developments make designing the workflow more important. When an assistant can request data, start a processing job, and present an interface, the workflow becomes richer. It must still be understandable. I want to reconstruct how a request became an operation and how that operation produced the result I am looking at.

Where would I start from, without building more than what is needed

For our team I would start with a limited and read-only delivery. I would prepare a testable example, clarify the metrics and compare the result with the sources. If the problem is above all to always collect the same data, I would invest in repeatability. If the need arises to interrogate them flexibly through an AI application, I would evaluate available MCP capabilities. The gateway would come when configurations and access really require a management point.

I would not transform this path into a one-size-fits-all prescription. A company may already have a reliable database; another may not yet know what a column means in their report. In the first case the connection can be the useful step; in the second it risks accelerating confusion. This is why, in my reading, the number of connected tools does not measure the maturity of a decision-making system.

The final criterion is simple to formulate, but requires work: where is the data, who requests it, who can act, what is transformed and who verifies the result? If the team knows the answer, they can choose file, API or MCP with a reason. If the team cannot answer, the new link may make the process faster without making it more understandable. I would like to get both, before calling it an improvement.

FAQ

Does MCP replace APIs?

No. An MCP server can use a service's APIs to expose capabilities to an AI application. MCP organizes the exchange of context and tools; the API can be the interface to the source. The two can coexist in the same process.

Does MCP guarantee updated data in real time?

No. Data freshness depends on the source, the tool's behavior, and any cached copies. The time a request is made does not necessarily match the time the data describes. These conditions need to be checked and stated.

Do you need an MCP gateway to get started?

Not necessarily. It should be evaluated when multiple links require configuration, access or routing management. The functions depend on the product chosen. A first case with only one server can work without this intermediary.

Does connecting AI mean allowing it to modify systems?

No. Reading data and writing changes are different capabilities. The project should expose only the operations it needs and apply appropriate permissions. A suggestion from the assistant should not automatically become a change to campaigns or company data.

Do you need to program to use MCP?

Not always: some applications offer configurable links. Availability, capacity and conditions must be verified in the specific product. Building or maintaining a server and integration may require technical skills. The absence of code in the interface does not eliminate the verification work.

Sources, method and author

Training guide with primary technical sources verified on November 2, 2026. The marketing case, function names and exercise are illustrative; they do not describe tests performed, customer data or measured results. The patterns are made in code and represent conceptual paths, not statistics. The position and the operational criterion express Giorgia's reasoning; Feature support must be verified in the chosen products.

I am Giorgia Palazzo, consultant, entrepreneur and teacher. I connect strategy, data, AI and technology implementation to company decisions. Here I explain how to read an architecture before adopting it, making criteria, limits and responsibilities explicit.