MCP: when AI agents start using tools
AI agents are rapidly changing the way we build software. They are no longer limited to answering questions, completing a function, or generating snippets of code from a prompt. Increasingly, they can carry out complete tasks, retrieve information, make decisions, and use external tools as part of a development workflow. That shift matters because it opens up a much more interesting possibility than asking AI to do everything on its own: letting agents rely on specialized tools whenever those tools can perform a specific task better, faster, or more efficiently.
This is where MCP, the Model Context Protocol, comes in. MCP is an open standard that allows AI applications and agents to connect to external systems, discover the capabilities available to them, and use those capabilities when needed. The official documentation describes it as a common interface between AI applications and external data sources, tools, and workflows: a way to build an integration once and make it accessible to different MCP-compatible clients.
Official Model Context Protocol documentation
From agents that generate code to agents that use tools
This shift can have a particularly significant impact on software development. Coding agents are very good at interpreting requirements, reasoning about a problem, and producing code, but not every engineering task needs to be solved through probabilistic generation. If a specialized tool can validate a model, apply a known architecture, or generate hundreds of files deterministically, asking an LLM to write those same files one by one means using AI for work that can be handled far more efficiently.
MCP makes it easier to separate those responsibilities. The agent can focus on understanding what we want to build, reasoning about the domain, and deciding which actions need to be taken, while external tools handle the tasks they were specifically designed to perform. This suggests a different architecture for development agents: AI reasons, specialized tools execute.
The distinction becomes even more relevant once we move beyond small examples and start dealing with real systems. An enterprise application may involve hundreds of classes and large numbers of repositories, services, controllers, DTOs, endpoints, tests, configuration files, and infrastructure components. If all of that is generated directly by an LLM, every element consumes tokens when it is produced and continues to consume context whenever the agent needs to read it, modify it, or check that everything remains consistent across later iterations.
Not all code needs to be generated token by token
This is one of the ideas we consider most important. Tokens are extremely valuable when they are used for reasoning, interpreting requirements, or solving problems that genuinely require intelligence. They are much less valuable when they are used to produce large amounts of code that follow rules and architectural decisions we already know.
A domain model can express concepts, properties, types, associations, compositions, inheritance, and other design decisions in a relatively compact representation. That same model can later be translated into a much larger amount of code. If the agent works with the compact representation and a specialized tool handles the transformation, we can dramatically reduce the amount of code the LLM itself needs to generate and keep in context.
If your project contains millions of lines of code, it makes little sense to spend millions of tokens asking a probabilistic model to generate code that follows rules you already know. When that implementation can be derived from a domain model, deterministic generation can produce it in seconds rather than relying on long agentic generation cycles, while consistently applying the defined architecture, conventions, and compliance requirements by construction.
That has a direct impact on cost. Structura is designed so that AI works with a compact representation of the domain, while large-scale code generation is handled afterwards by deterministic generators. Our current reference puts token usage at up to around 1,000 times lower than full-stack generation performed entirely with AI. The difference does not come from using a cheaper model to write the same code. It comes from avoiding the need for the LLM to write that code token by token in the first place.
The larger the project, the more meaningful this difference becomes. An agent can use its context to create and refine a much smaller representation of the domain, while the generator turns that model into a complete codebase in seconds. Beyond reducing token usage, the generation process is no longer probabilistic: given the same model and configuration, it applies the same architectural rules, conventions, and design decisions every time.
AI works with the compact domain model; specialized tools generate the implementation.
Domain modeling as a tool for AI agents
This approach fits naturally with Structura, our web-based tool for domain modeling and class modeling. Structura provides visual and textual representations of a domain, supports concepts relevant to Domain-Driven Design and class modeling, validates models, and uses them as a source for deterministic code generation. AI can help create or refine the model, but it does not also need to bear the cost of producing everything that can be derived from that model automatically.
The model therefore becomes an intermediate layer between intent and implementation. Instead of going directly from a prompt to thousands of lines of code, we can move from requirements to an explicit, reviewable, and validatable domain model, and then use that model to produce the implementation. For architects, this provides a representation of the system that is not tied to a specific technology. For teams, it provides a shared source of truth. For agents, it means working with far less context and delegating the most repetitive parts of development to a specialized tool.
This is where MCP becomes particularly valuable. If we want agents to work in this way, they need access to modeling, validation, and code generation capabilities from within their own environment. That is why we built the Structura MCP server.
Structura as an MCP server for coding agents
The Structura MCP server allows any MCP-compatible agent to connect directly to Structura and use its capabilities as part of its own workflow. It can work with projects, create or load models, validate them, and use the available code generators. The connection is made through the Structura MCP endpoint and the user’s standard authentication, without having to manually move models, prompts, or files between tools.
Connect to the Structura MCP server
This turns Structura into more than a modeling tool used through a browser. It can also act as a domain modeling and deterministic code generation tool for AI agents. If a coding agent needs to define a domain, build a class model, validate that model, or generate an implementation from it, it can use Structura through MCP instead of attempting to solve the entire problem through direct code generation.
The goal is straightforward: let the agent spend its tokens where they deliver the most value, while delegating to Structura the work that can be performed faster, more economically, more predictably, and deterministically.
MCP in action
The easiest way to understand what changes when an agent can use Structura through MCP is to see it working. In the demo accompanying this article, our founder, Pedro J. Molina, starts with a natural-language request and shows how an MCP-compatible agent can use Structura to work with the domain and move from an idea to running software, without manually transferring context between tools.
The workflow is remarkably simple and fast. The agent works with the model, Structura handles the specialized tasks, and code generation takes around 20 seconds. We will not give away everything that happens next here: it is far more useful to watch the full demo and see just how far the workflow can go.
▶️ Watch the full MCP for Structura demo
If you already work with an agent that supports the Model Context Protocol, you do not have to stop at the demo. Connect it directly to Structura and try the workflow with your own models.