How I Connected AI Models to Any Service Without Extra Code
How I Connected AI Models to Any Service Without Extra Code - Photo by Bernd 📷 Dittrich on Unsplash
Alright, let’s get straight to it. I ended up building an MCP server almost by accident, and honestly, it’s way more useful than I expected. If you’re wondering what an MCP server is, let me break it down in my own words: it’s basically a bridge between an AI model and another service. That could be a local database, a remote API, or something like Google Analytics. The whole idea is to let your AI model talk to other services, fetch data, push results, or just generally be more useful.
Historically, this was called “function calling.” OpenAI used that term for a while. Now, the mainstream name is Model Context Protocol (MCP), and that comes from Anthropic—the folks behind Claude. They coined MCP, and it’s catching on. If you haven’t checked out the Model Context Protocol yet, I really recommend it. It’s a protocol, but more importantly, it’s a practical way to connect the dots between your AI model and whatever other service you want to hook up.
Why MCP Servers Matter
Recently, I saw that Google released a Python MCP server for Google Analytics. Brilliant move. Imagine having a dashboard where you can literally talk to your Google Analytics data using an AI model—OpenAI, Claude, Mistral, whatever. You can ask questions, get insights, and automate stuff that used to be a pain.
That got me thinking, so I built my own little MCP server. Here’s what I learned and how I set it up.
Anatomy of My MCP Server
With MCP, you need specific endpoints. The protocol is pretty clear about this. It’s kind of like OAuth for authentication, but for connecting models and services. There’s this “well-known” endpoint, which is new-ish. It’s not strictly mandatory, but it’s recommended now. Then you’ve got your model context endpoint, usually something like /model-context/v1. That’s where your data schema lives.
In my setup, I’ve got a local data schema. Here’s a quick look at the structure:
1// server.ts (using Fastify)
2import Fastify from 'fastify';
3import dotenv from 'dotenv';
4
5dotenv.config();
6
7const fastify = Fastify();
8const PORT = process.env.APP_PORT || 3000;
9
10fastify.get('/.well-known/model-context', async (request, reply) => {
11 return {
12 "@context": "https://schema.org",
13 "schemaVersion": "v1",
14 // ...your schema here
15 };
16});
17
18
19*How I Connected AI Models to Any Service Without Extra Code - Photo by [GuerrillaBuzz](https://unsplash.com/@guerrillabuzz) on [Unsplash](https://unsplash.com/photos/diagram-7hA2wqBcSF8)*
20
21fastify.get('/model-context/v1/content', async (request, reply) => {
22 // Return some data
23});
24
25fastify.get('/model-context/v1/model', async (request, reply) => {
26 // Prediction, regression, whatever you need
27});
28
29fastify.get('/model-context/v1/extra', async (request, reply) => {
30 // Third-party service integration
31});
32
33fastify.listen({ port: PORT }, (err, address) => {
34 if (err) throw err;
35 console.log(`Server running at ${address}`);
36});
You can add more endpoints for specific tasks. For example, if you want to do logistic regression or anything data science-y, just add another route. If you want to keep it simple, that’s fine too.
I split my routes into different files, but you could totally keep everything in one file if you want. My main server file is server.ts. I use Fastify, but you could use Express.js or NestJS. I also use an .env file to store generic data for the API.
Project Structure and Build
Here’s how I set up the build process:
- TypeScript: I use
tscto compile to JavaScript. Mytsconfig.jsonoutputs to adistfolder. - Scripts: In
package.json, I’ve got scripts for building, cleaning up (rimraf), and running the server in dev mode withts-node-dev. It’s like nodemon but better for TypeScript. Use it in development, not production. - Dependencies: Fastify for the server, dotenv for environment variables, and a few dev dependencies for building and cleaning.
Here’s a snippet from my package.json:
1{
2 "scripts": {
3 "build": "tsc",
4 "clean": "rimraf dist",
5 "dev": "ts-node-dev server.ts",
6 "start": "node dist/server.js"
7 },
8 "dependencies": {
9 "fastify": "^4.0.0",
10 "dotenv": "^16.0.0"
11 },
12 "devDependencies": {
13 "ts-node-dev": "^2.0.0",
14 "typescript": "^5.0.0",
15 "rimraf": "^5.0.0"
16 }
17}
Publishing and Documentation
I’m putting the whole thing on GitHub, so you’ll have everything you need. The repo will be at open-data-for-science/mcp-server-api. The README explains the structure, why I use the “well-known” endpoint, and how to define your public semantic schema with JSON-LD and context. That’s important for interoperability.
I also use a utility file to keep the code clean, and I fixed a little typo in my .env (should be APP_PORT, not REAME_TO_PORT—oops). I use Copilot to generate commit messages, which is a nice little hack.
How I Connected AI Models to Any Service Without Extra Code - Photo by marko marko on Unsplash
Wrapping Up
So yeah, that’s my accidental MCP server. It’s actually pretty simple. At the end of the day, an MCP server is just a protocol—a way to let your AI model and another service talk to each other. If you want to dig deeper, check out the Model Context Protocol docs. There’s a lot to learn, and honestly, it’s a game changer for making AI models more useful in real-world applications.
If you want to look up more, just search for “function calling” or “MCP.” They’re basically the same thing.
“An MCP server is just a protocol—a way to let your AI model and another service talk to each other.”
Happy AI learning!
Key Takeaways
- MCP (Model Context Protocol) servers bridge AI models and third-party services—local or remote, databases or APIs.
- Endpoints matter: Follow the protocol for
/well-knownand/model-context/v1endpoints. - You can use Fastify, Express.js, or NestJS—whatever you’re comfortable with.
- Keep your build process clean: Use TypeScript,
ts-node-devfor development, and proper environment variables. - Check out the Model Context Protocol docs for more details and best practices.
- Don’t overthink it: An MCP server is just a way to connect your model to the outside world.
“If you want to make your AI model actually useful, let it talk to your data.”
🤔 Learn more about me on Dev.to
Sometimes, the best tools are the ones you build by accident.
Pierre-Henry Soria
#Accidental Project #Ai Integration #Mcp Server #Model Context Protocol #Nomad #Tasks #Tech #Third-Party Services