# Learnings from Building an MCP Server > Source: > Published: 2026-07-21 23:23:51+00:00 I built an MCP server for [nuzur](https://nuzur.com/), a project I've been working on. It fits naturally into my workflow and helps me automate flows from schema design to data changes. In this post I want to share what I learned during the process. MCP (Model Context Protocol) is an open standard, created by Anthropic in 2024, for connecting AI models to external tools and data sources. Think of it as a universal adapter for integrating with any AI assistant or agent. I started by building CRUD operation tools into the MCP server. These work, but they're expensive (especially if your payloads are large), and it can take the agent several minutes to complete a task. Here's a more specific example: nuzur manages projects, and each project can have n project versions. Each project version holds entities (with their fields), relationships, and enums. I asked the agent to make some changes to a project: create a new project version, add an entity, and modify another. My initial design gave the agent a tool to get the latest project version and a tool to create or update one. It worked, but it used up all my tokens and took around 15 minutes to complete. **The problem** is that models usually have a hard time with large payloads, and making specific changes to deeply nested structures is expensive. **The solution** is to create granular tools so the agent never has to read and parse the full payload. The server keeps track of the overall structure, and the agent only gets the parts it needs. How does this translate to the example above? I built granular tools to manage entities, fields, relationships, and enums, and I also added a tool that returns a lean version of the project version to give the agent overall context when needed. This cut the run time from 15 minutes to under a minute for the same changes, and token usage went down dramatically as well. **The takeaway:** keep tools granular, keep payloads tight, and limit them to only the necessary data. Another helpful trick is to ask the agent that used your MCP server for feedback on the tools—what took a long time and what could be improved to make things smoother. This is a small one but useful: you can embed your skills in the MCP server as prompts. That way they stay up to date with your code, and users get the latest version without having to manually download or update the skills on their client. Along the same lines, you can serve resources from the MCP server to complement your tool descriptions. This improves the user experience, streamlines workflows, and reduces rework—and like prompts, resources can be updated dynamically without touching the client. If I were starting over, I wouldn't build the CRUD tools at all. It's tempting to mirror your existing API, but agents don't consume APIs the way programs do—they pay for every token they read. Designing for the agent from day one means starting granular, keeping responses lean, and treating context as a budget. I'd also make agent feedback part of the development loop earlier. Some of my best tool improvements came from simply asking the agent what slowed it down after a session — it's the cheapest usability testing you'll ever run. An MCP server isn't just a wrapper around your product; it's an interface designed for a very different kind of user. Once I started thinking about it that way, every design decision got easier. If you want to see these ideas in practice, the [nuzur MCP server](https://nuzur.com/docs/mcp-connect) is live—try it out and let me know what you think.