Introduction
I was sold on using AI pipelines the moment I found n8n. It was impressive the potential it has. I didn't want to only be a user, I wanted to know how it works. As many developers I use AI for everyday assistance but that's just the tip of the iceberg. I wanted a deep dive into AI application development. The first thing I felt I needed to know was the Model Context Protocol (MCP), "Why it is useful and how it works?".
The big deal with MCP
As the official documentation states, MCP is an open-source standard for connecting AI applications to external systems. Let's think of MCP as the USB-C for AI applications. This protocol provides a standardized way to connect AI applications to external systems.
One example of this applied is a simple Claude or ChatGPT chat with access to an internal enterprise database and tools around the business model empowering the user; agents taking decisions on your behalf; direct connection with many of your services like Figma, PostHog, GitHub, and the list keeps growing.
First Steps
I got started with an MCP server, because I already had a good MCP Client working, Claude. When working in the server side you have three main concepts or capabilities: Resources, Tools, and Prompts. I began with Tools which are basically functions your LLM can use.
Another big thing to have in mind is that an MCP Server can be STDIO-based or HTTP-based. Each has different purposes. STDIO is meant for local single user and performant tools. While HTTP ones are for web applications and distributed systems, think of them as an API. Once I understood STDIO vs HTTP, it all clicked. I understood why some tools are CLI-based and others are full services.
I expected a bigger wall to start with MCPs, a high ceremony along with heavy AI Engineering concepts. While writing a simple get_current_time tool, what I encountered wasn't a complex protocol, instead a well-defined contract to build upon. Below we can see the implementation of the tool which is basically the registerTool block which is the only thing we need to care about. The rest is boilerplate.
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import z from 'zod';
const server = new McpServer({
name: 'my-mcp-server',
version: '1.0.0',
});
server.registerTool(
'get_current_time',
{
description: 'Get current time',
},
() => {
return {
content: [
{
type: 'text',
text: `Current time is: ${new Date().toLocaleString()}`,
},
],
};
},
);
async function main() {
const transport = new StdioServerTransport();
await server.connect(transport);
console.error('My MCP running on stdio');
}
main().catch((error) => {
console.error('Fatal error in main():', error);
process.exit(1);
});
Once integrated with my client, in this case Claude Desktop, the tool is available for us by asking Claude to "Get the current time" in a prompt to use it.
Keep pushing on MCPs
MCP is the door that gives an LLM the power to use your system. It can be as simple as a tool to get the current time and as complex to manipulate a whole web application through a chat. One of my favorite examples is the PostHog MCP that enables you to build insight graphs by telling the LLM what you would like to see.
As proof of understanding, I wanted to build a complex MCP server. I ended up with a tool named gitstoria. This tool helps you attach reasoning and process notes to your git commits via any MCP-compatible LLM client. Every time you commit, gitstoria queues the commit for review; your LLM reads the diff, writes a structured session log, and stores it locally alongside your repo history.
How it works:
- You make a commit, a
post-commithook fires and records the commit hash in a local SQLite DB - You ask Claude to log what you worked on
- Claude calls the
gitstoriaMCP tools, reads the diff, and writes a session log back to the DB
You can take a look at the full code and download the package if curious:
- GitHub Full Code: https://github.com/marcochavezco/gitstoria
- Package download:
npm i gitstoria
The roadmap is forking
I see two paths to follow up, workflow automation tools/ecosystem and AI engineering. Each route is worth exploring; on one hand tools like n8n can help you to take processes, reduce friction, and end up with real efficiency gains; and on the other hand, taking a deep dive into how an LLM works and what is under the hood. I wanted to know how tools like n8n worked, so I chose to go deeper.

Top comments (0)