Skills, Tools, and MCPs: How AI Goes From Chatbot to Co-worker

The previous post in this series covered what large language models are, how they're trained, and the basic mechanics of inference. The short version: an LLM is a very sophisticated pattern predictor. It generates plausible text, not verified output, and it should be treated accordingly.

That framing, while accurate, describes what AI was a couple of years ago. The systems showing up in engineering software today are built on top of that foundation, but they've grown considerably. The three concepts doing most of the work are skills, tools, and MCPs (Model Context Protocol). None of them require a software background to understand, and all three are worth knowing about if you're evaluating AI tools for practice.

Skills: Giving a Model Specialized Knowledge

A base language model is a generalist. Trained on a broad sweep of human writing, it knows a little about almost everything and a lot about nothing in particular. Skills are how you change that.

In practice, a "skill" is a set of specialized instructions or knowledge loaded into the model before it does any work. This could be a detailed system prompt that tells the model to follow a specific methodology, a batch of firm-specific documents it can reference, or fine-tuning that has baked domain knowledge directly into the model's weights. The result is a model that behaves like a specialist rather than a generalist.

For structural engineering, this matters because a generic AI and an AI loaded with guidance on basic structural load path behave very differently on technical questions. The former will give you a plausible-sounding answer. The latter is using some specific structural engineer knowledge, which reduces (though does not eliminate) the risk of useful-sounding errors.

Tools: Letting the Model Take Action

Skills address what a model knows. Tools address what it can do.

A base LLM is a closed system. Its responses are generated entirely from its training data and whatever you put in the context window. It cannot check anything, run anything, or retrieve anything outside of that. This is the core reason why raw LLMs have trouble with specific numerical questions, current code citations, and anything that requires looking something up.

Tool use changes that. When a model has access to tools, it can reach outside itself: run a Python script, search the internet, query a database, fetch a document, check a live data source, or call a calculation API. The model decides when a tool is needed, calls it with the right inputs, gets the result back, and incorporates that result into its response.

The implications for technical workflows are significant. An AI with the right tools can run an actual beam analysis and report the numbers rather than approximate them. It can pull the current wind speed from a mapped database rather than cite a value from training. It can check your project management software for open RFIs rather than ask you to summarize them. The model is no longer just a text generator; it's a coordinator that can route tasks to reliable external systems and weave the results together.

Tool use does not solve the accountability problem. The model is still deciding when and how to use a tool, which introduces its own failure modes. But it moves AI from a system that produces plausible language to one that can produce verifiable outputs on specific, bounded tasks.

MCP: The Standard Connection Layer

If tools let a model connect to external systems, MCP is the protocol that standardizes how those connections are built.

Model Context Protocol is an open standard, published by Anthropic in late 2024, that defines a common interface for connecting AI models to external data sources and capabilities. Before MCP, every AI integration was custom: one team built a connector to Procore, another team built a connector to a structural calculation API, and neither connector worked with any other AI system. Every new pairing was a new engineering project.

MCP works like a standardized electrical interface. The outlet and the plug follow a common standard, so any compliant device can connect to any compliant outlet. Under MCP, an external service builds one "MCP server" that exposes its capabilities in a standard format. Any MCP-compatible AI can then use that service without custom integration work.

For engineers evaluating software, the practical implication is interoperability. A structural analysis tool that builds an MCP server can be accessed by Claude, by a custom internal AI, or by any other MCP-compatible system. The connection is not locked to one vendor's AI product. This is starting to look more like standard CAD file formats than proprietary siloed software, which is a healthy direction for the industry.

The other implication is composability. An AI workflow can pull from multiple MCP servers in a single session: fetch a project record from a CRM, run a calculation via an engineering API, check the result against a code database, and write up the output as a formatted report. Each service stays in its lane; the AI coordinates between them.

How These Three Work Together

Skills, tools, and MCP are most useful in combination. A model without skills might use a calculation tool correctly but misinterpret the results in the context of a specific code provision. A model with skills but no tools is still guessing at anything that requires a live lookup or complex math. A model with tools but no standard protocol is only useful in environments someone has custom-built for it.

Together, they describe what a well-designed AI workflow actually looks like in practice: a model with relevant domain knowledge, connected to verified external systems through a standardized interface, with a human reviewing the outputs before anything gets stamped.

The gap between "AI chatbot" and "AI that is genuinely useful in a structural engineering workflow" is not primarily about the model getting smarter. It's about these three layers being in place and working correctly.

What This Means for Practice

None of this removes the licensed engineer from the process. Skills can encode the right code provisions, but they don't give the model judgment about when a provision applies to an unusual condition. Tools can run a calculation, but someone has to define the inputs and validate that the model set up the problem correctly. MCP makes integrations more seamless, but it does not make the outputs automatically trustworthy.

What these capabilities do is change where engineer time goes. When an AI can reliably coordinate project setup, gather basic information from pdfs, run preliminary checks, and package documentation, the engineer spends more time on the work that requires an expert. The AI is not performing engineering, it is coordinating the use of different tools to help the engineer work more efficiently.

Clearspan is built on that model. We use skills to describe structural concepts, tools to run verified calculations, and provide an MCP for use by engineers. The output is a design file that is ready for review and editing by the engineer.

If you want to see how this works in practice, learn more about the Clearspan workflow.

---

This is the second post in Clearspan's series on AI for structural engineers. Read the first post: LLMs for Structural Engineers: How AI Language Models Actually Work.