APIs & MCPs: Essential acronyms for connecting LLMs to data, tools, and services
How the connective tissue of AI systems works, why it matters for social work and law, and what has changed since I last wrote about it
Last year, my colleagues and I published an article in the Journal of the Society for Social Work and Research that guided social work researchers on using application programming interfaces (APIs) to connect to large language models (LLMs) and other web-based AI services. The paper included step-by-step Python code, screenshots, and detailed explanations of concepts like endpoints, API keys, and batch processing. We spent considerable effort making these technical ideas accessible to readers who had never written a line of code.
One exchange with a reviewer stands out. We were asked to clarify that AI models are not connected to the internet and do not inherently know about APIs or current documentation. At the time, that was a reasonable and accurate correction. The major LLMs operated within the boundaries of their training data and could not browse the web or access external services on their own.
That was roughly a year ago. The landscape has shifted considerably.
I still use APIs every day. They remain foundational infrastructure for anyone working with AI tools in research or practice. What has changed is that I almost never write API code by hand anymore. The AI tools themselves have become capable of handling that work. When I need to connect to a service, I describe what I need, and the model generates the code, tests it, and troubleshoots errors. The manual coding workflow we documented so carefully in that paper has been largely automated by the very technology we were writing about.
This is not a story about that article becoming obsolete. It is a story about the pace of change, and about why understanding these concepts matters even more now than it did then.
What an API actually does
An API is a structured way for one piece of software to talk to another. When you use a weather app on your phone, the app does not generate forecasts. It sends a request through an API to a weather service, receives data back, and displays it on your screen. The app and the weather service are separate systems; the API is the connection between them.
In research, APIs allow you to send data to a service and receive processed results. I use an API via OpenRouter to access various language models for tasks such as classification, translation, summarization, and extraction. The data leaves my computer, gets processed on a remote server, and comes back with the results. That basic request-and-response pattern is the same whether you are geocoding addresses through the U.S. Census Bureau, retrieving article metadata from PubMed, or sending text to an LLM for analysis.
The key concepts are straightforward. An endpoint is the specific web address where you send your request. An API key is the credential that authenticates you with the service. The request contains your data and instructions. The response contains the results. Every API interaction follows this pattern, regardless of the service.
What has changed: from hand-coded connections to MCPs
When we wrote the JSSWR article, connecting an LLM to an external service meant writing Python code to handle authentication, construct the request, send it to the endpoint, parse the response, and manage errors. It was not impossibly difficult, but it required a working knowledge of programming and a willingness to debug.
The emergence of the Model Context Protocol (MCP) has substantially changed this dynamic. MCP is a standardized way for AI models to connect to external tools, data sources, and applications. Rather than writing custom code for each connection, MCP provides a common framework that any compatible tool can use to plug into an LLM.
Think of it this way. APIs are like having a phone number for every business you want to contact; you need to know each number, the right way to ask for what you want, and how to interpret the response. MCP is more like a universal switchboard operator. You tell the operator what you need, and it handles the connection, the protocol, and the translation for you.
In practical terms, this means I can connect Claude to my Google Calendar, Google Drive, Gmail, Notion, and a growing number of other services through MCPs. The LLM can then read my documents, check my schedule, search my email, or pull data from a database to complete a task. I did not write code to make any of these connections. I enabled them through a configuration interface, and the model handles the rest.
This is a significant development. The barrier to integrating AI with other tools has dropped from “you need to know Python” to “you need to know what you want to accomplish.”
Why both concepts still matter
MCPs have not replaced APIs. They sit on top of them. When Claude connects to Google Drive through an MCP, an underlying API still handles the actual data exchange. MCP standardizes and simplifies the connection layer, but the API is still doing the work.
This distinction matters for several reasons. First, not every service has an MCP integration yet. If you need to connect to a specialized database, a government data portal, or a niche research tool, you may still need to work with the API directly. Second, understanding what happens at the API level helps you make informed decisions about data security and privacy. When you enable an MCP connection, your data is still traveling to external servers. Knowing that an API request sends your data to a specific endpoint, where it is processed under specific terms of service, is essential for responsible use, particularly when working with sensitive client data, protected health information, or privileged legal communications.
Third, and most practically, understanding these layers helps you evaluate what AI tools can and cannot do. When someone tells you their AI system “integrates with everything,” you now have the vocabulary to ask the right questions. What APIs does it connect to? What data gets sent? Where is it processed? What happens to it afterward?
What this looks like in practice
Here is a concrete example. I frequently use OpenRouter, a service that provides API access to dozens of language models through a single endpoint. Instead of maintaining separate API keys and code for OpenAI, Anthropic, Google, Mistral, and others, I route requests through OpenRouter and switch between models as needed. This is an API-level integration that gives me the flexibility to choose the right model for each task.
At the same time, I use MCP connections in Claude to interact with my institutional tools. If I need to find a document in Google Drive, draft a response based on its contents, and schedule a meeting to discuss it, Claude can handle all of that through MCP connections without me switching between applications or writing any code.
These two patterns, direct API access for specialized research tasks and MCP connections for everyday productivity, coexist in my daily workflow. Neither has eliminated the other.
What you need to know (and what you do not)
If you are a social work or law professional, you do not need to know how to build APIs or develop MCP servers. That is engineering work, and there are people who specialize in it.
What you do need is a working understanding of these concepts. You need to know that when an AI tool connects to an external service, an API is involved, and that connection has implications for data privacy and security. You need to know that MCP is making these connections more accessible, but that the underlying mechanics have not changed. You need to know that the ability to connect AI models to your existing tools and data sources is what transforms a chatbot from a novelty into a functional component of your workflow.
When you are evaluating an AI tool for your organization, these concepts will help you ask better questions. When you are designing a research workflow, they will help you understand what is possible. When you are teaching students, they will help you explain not just what AI does, but how it does it.
The acronyms are accumulating. APIs, MCPs, LLMs, RAG, NLP. The terminology can feel overwhelming. But the core ideas are not complicated. Software needs structured ways to talk to other software. Language models need structured ways to connect to tools and data. Everything else is an implementation detail.
The field is moving fast enough that the specific tools will keep changing. The concepts will not. Understanding what an API is and what an MCP does gives you a stable foundation for evaluating whatever comes next.