Tag: Tools

Últimamente estoy siguiendo de cerca todo lo que rodea al protocolo MCP (Model Context Protocol), y hace poco me encontré con un proyecto que tiene bastante sentido: MCPHero.

La realidad es que aunque MCP está pegando fuerte, muchas librerías de IA “tradicionales” como openai o google-genai siguen sin soporte nativo para MCP. Solo soportan tool/function calls. MCPHero viene a solucionar precisamente esto: hacer de puente entre servidores MCP y estas librerías.

Lately I’ve been closely following everything around the MCP protocol (Model Context Protocol), and recently I found a project that makes a lot of sense: MCPHero.

The reality is that although MCP is taking off, many “traditional” AI libraries like openai or google-genai still don’t have native MCP support. They only support tool/function calls. MCPHero comes to solve exactly this: make a bridge between MCP servers and these libraries.

What is MCPHero?

MCPHero is a Python library that lets you use MCP servers as tools/functions in native AI libraries. Basically, it lets you connect to any MCP server and use its tools as if they were native OpenAI or Google Gemini tools.

After my previous article about agent-centric programming, I’ve been researching more advanced techniques for using Claude Code really productively. As a programmer with 30 years of experience, I’ve seen many promising tools that ultimately didn’t deliver on their promises. But Claude Code, when used correctly, is becoming a real game-changer.

Beyond the basics: The difference between playing and working seriously

One thing is using Claude Code for experiments or personal projects, and another very different thing is integrating it into a professional workflow. For serious projects, you need a different approach:

Throughout my career, I’ve seen many things change. I’ve gone from Borland to Visual Studio, from vi to Sublime Text, from Sublime to VS Code… And believe me, each change was a deliberate decision that cost me weeks of adaptation. But what’s happening now with AI tools is something completely different.

I’ve found myself using Copilot in the morning, trying Cursor in the afternoon, and checking out Claude Code before going to bed. And I’m not alone. Developers have gone from being faithful as dogs to our tools to being… well, promiscuous.

In my experience with mobile development, I’ve seen how apps become increasingly complex and projects grow uncontrollably. I remember perfectly that feeling of having thousands of lines of code and not being sure what was really being used and what wasn’t.

That’s why I was so struck by the tool that Sentry (formerly from Emerge Tools) just released as open source: Reaper. An SDK that does something that sounds simple but is tremendously useful: find dead code in your mobile applications.

I’ve seen how certain standards and tools become indispensable when working with data. And if there’s one thing we’ve learned over these years, it’s that JSON is everywhere: APIs, logs, configurations, NoSQL databases… The question is no longer whether you’ll work with JSON, but when you’ll face that 15-level nested structure that makes you sigh.

The Problem We’ve All Lived Through

How many times have you had to write something like this?

A necessary reflection on the “AI-Native Engineer”

I read Addyo’s article about the “AI-Native Software Engineer” and, as a Principal Backend Engineer who has seen technological promises come and go for years, I have quite sincere opinions about it. Not all are comfortable to hear.

I’ve seen enough “revolutions” to separate the wheat from the chaff. And there’s a lot of both here.

What’s really working (honestly)

1. AI as copilot, not as pilot

The article’s metaphor about treating AI as a “junior programmer available 24/7” is accurate. In my experience working with teams, I’ve seen developers use GitHub Copilot and Claude effectively to: