In May 2025 we built an internal tool at our previous company. It was an MCP server that connected Claude to our PostgreSQL database. The first version took an afternoon. The version we actually used in production took three months.

This is the story of those three months and why we left to build Toolcall.

What we wanted

The original goal was simple. Our data team kept getting Slack messages. "Hey, can you pull the conversion rate for cohort X?" "What was MRR by region last quarter?" "Why is signup completion down this week?"

Each question took ten minutes to answer if the data was easy and an hour if it wasn't. The data team was three people. The questions came from forty.

MCP had just been announced. We saw the demo where Claude queried a Postgres database via an MCP server and thought: this is exactly what we need. Let the rest of the company ask questions directly. Free up the data team for actual analysis work.

What we built first

A small Node.js service. About 200 lines. It exposed three tools: query_database, list_tables, describe_table. We deployed it to a small EC2 instance. Configured Claude Desktop to connect. Showed it to two engineers.

The first day was great. The engineers asked questions, got answers, said "this is incredible."

The second day was less great. One of them ran a query that scanned a 50-million-row table. The server held the connection for ninety seconds. While that query ran, three other people tried to use it and got timeouts. Slack lit up with complaints.

What we built next

We added connection pooling. Statement timeouts. Row count limits. Schema caching. Audit logging because we needed to know who was running what.

We added an admin UI to manage API keys. We added per-team access controls because the legal team didn't want sales reading the legal team's documents. We added rate limiting because we discovered that Claude would sometimes get into a loop and fire fifty tool calls in thirty seconds.

We added a status dashboard. We added health checks. We added pager rotation when the server went down at 3am on a Tuesday and nobody knew until people came in the next morning.

By month three we had a system that worked. We had also spent the time of two engineers building it. The data team's actual job had been sitting in the backlog the whole time.

The realization

We didn't build a useful internal tool. We built bad infrastructure.

The MCP server itself, the part that mattered, was the smallest piece. The 200-line version from week one was 80% of what users actually saw. The other three months were authentication, observability, rate limiting, deployment, on-call rotation. Things every team was going to need. Things nobody wanted to build twice.

We talked to fifteen other teams at the AI engineering meetup. Twelve of them had the same story. They'd built an MCP server. They were maintaining it. They wished someone else would maintain it.

That was the product.

What Toolcall is

We host the MCP server so you don't have to. You bring the data source, a database, an API, a SaaS account. We handle the server runtime, the auth layer, the observability stack, the on-call rotation, the deployment pipeline.

What you keep is the part that matters: the tools, the descriptions, the integration with your model. What we take is the part that's the same for everyone.

We're not the right choice for every team. If you have spare infrastructure capacity and unusual security requirements, run your own. If you're the type of team where building infrastructure is the point, do that. We'd rather you build well than use us reluctantly.

But for the teams that are three weeks into self-hosting and starting to realize the scope keeps expanding, we built this for you.

Where we are now

We're 50 customers in. The product is changing fast as we learn what people actually need. v0.2 just shipped with resource support and team workspaces. v0.3 will focus on observability: better traces, better metrics, better tooling for debugging tool calls that fail in weird ways.

If you're thinking about building your own MCP infrastructure, or already are and the scope is creeping, we'd love to talk. Email is on the homepage. We answer.