Construct.Chat Agents

[00:00] Hi, my name is Charley. I'm the founder of Construct.Chat. Today I'll be walking you through our platform and the agents that we've been creating, along with the MCP tools that we have available. So let's jump right in. If you want to learn more, of course, you can go to constructchat.com. Today I will be showing you our application. The application is hosted at app.construct.chat. On our platform, you'll be able to create new chats, and you can leverage any type of agentic chat interface and application agents to perform insights, do actions, and create

[00:45] various data. There are different large language models that you can leverage: from OpenAI, where you plug in your API key, your own agents that you create, any assistants. Of course, we have Google plugins that you can import, and various other types of large language models depending on what your needs are. Specifically, I created an agent here. You'll see it over here on the right. It is called the Procore Project Financials Insights Agent. What this does is provide financial insights to construction projects, allowing you to interact with your Procore data, specifically construction financials. It will leverage the API and MCPs to query information within your solution and

[01:30] give detailed responses based upon your requests and the details that you desire. There are different capabilities with agents that we can leverage. The first one is choosing the model that you want to use for this agent. Outside of that, we can give it the opportunity to run code, we can give it the opportunity to search the web, and of course we can upload any type of file for reference context. Those files will go through a RAG analysis and do query analysis and lookups for that type of data, specifically within the file search, where we can find that data and look it up. One of the key features and functionalities I'll be showing today, if I scroll down here, is

[02:15] the Procore MCP. This is an MCP that I created. Essentially, you enter your client ID, client secret, company ID, and the environment, sandbox or production, as well as the API key for Construct.Chat. Once that is provisioned, you'll be able to select from the plethora of different MCP tools. As of right now, I am just showing the list and show MCP tools. Of course, there are different opportunities to create, delete, or update various types of functionality within Procore. The whole idea is that you provide your agent with the tools necessary to gather the

[03:00] information or do the actions, so you can interact with it in your own language and it will then do those specific tasks for you. Once you've selected your tools, we can provide other tools and capabilities, like a calculator, and then we can save it. Once we save it... I did have a chat already created, so we can leverage one of the chats that was created to provide some deeper insights on this. What I asked it, essentially, is "What projects am I working on?" What you'll see here is that it ran the list projects endpoint, and it provided the projects that I currently have available. I then said, "Hey, I want to actually know more about this project," so this

[03:45] Sparkling Skyrise project, and I gave it the ID and said, "Hey, I want to learn more about this." It ran the get project details tool, and you'll see it made this request here, and from there it was able to create a detailed response outlining all the specifics of that project. Of course, we want to know even more about this construction project, so I specifically said, "Hey, tell me more about the project financials." That leveraged more of the MCP tools and essentially ran many different API requests, performing detailed insight into what those current details or data are. From there, it produced a response and was able to provide a

[04:30] detailed response for each specific functionality that we were looking for. It gave breakdowns, budgets, estimates, and recommendations. When it brought us to the end, of course, we can keep interacting with it, telling it what we want deeper insight on, or we can have it run calculations and do various tasks for us. This is, of course, just a starting point. I have over 700 MCP tools for Procore created, and I'm currently working on MCP tools for other construction software for you to leverage cross-functionally between the different technologies in your tech stack. What this is also doing: I have the Construct.Chat API key that I shared

[05:15] earlier, and what this does is send a request to our Construct.Chat API dashboard. This allows me to identify how these MCP tools are being utilized and whether they're succeeding or failing, so if I need to update them, put time or attention into them, or just see which ones are being leveraged and utilized. It's quite important. When a new customer comes on, I'll create a new API key here, and that API key will be plugged in and used when using the MCP tools. When we look at the recent tool calls here, we're able to get deeper insight into: when this ran list projects, what was the key result? What was the request? What was the URL that

[06:00] it requested? Any query parameters, headers, and the arguments for it, and then the response that it provided back to the chat interface. This is super helpful: being able to gain insight into how they are functioning, updating them if necessary, and, further down the line, being able to automate this data and feed it into a fine-tuning model. Then we can give an agent the ability to leverage our own large language model that is fine-tuned on construction-specific data. That will make it even more intelligent and give it more capabilities in terms of

[06:45] construction responses, and provide deeper intelligence for the construction industry. If there are any failures, like we see here, where there is a failure on this one, it gives us the opportunity to dive deeper into why it failed and what needs to happen. We may need to update the MCP; maybe they changed the URL, or there are different parameters that are required to submit this. This gives us that granularity into understanding what's going on from that interface. Then, of course, there are analytics. When we run different tool calls, we'll be able to see different graphical views of how they're functioning and which ones are being utilized at what frequency. How this essentially works... well, I

[07:30] can actually just show some of the tools. I did run a test. This is the API test, API verification. When this ran, I plugged in my credentials and I'm running a JavaScript application that runs some tests on it. You'll see here that currently I have about 735 tools created. Then it went through and tested list projects to make sure everything's functioning and working appropriately. It listed the projects here, and everything was successful. As for how this is working, I'll bring you into the codebase. Within the codebase, we're in our Procore MCP, in the source folder, and specifically we have our index.ts, which provisions the

[08:15] rest of the folders. We then dig into the client. This client provides the common clients for how we're interacting with Procore: authentication and the instance, and then any errors if they come up. We then have our list of endpoints that we're leveraging and utilizing. What I've done so far is all of Construction Financials and most of Core. I'll be working on the various other modules that Procore has to offer soon, like the Project Management module. When you go into here, this will load quickly, hopefully, and this contains all of the specific endpoints that are available, or the modules for the endpoints, within the

[09:00] Core module of Procore. There are different directories under the Core module, and within those, this outlines all of the specific endpoints that are available to be leveraged and utilized, in addition to the actions associated with them. The same thing goes for Construction Financials here. Once we go back and go into the configuration, this is where we can configure our environment variables: all of the authentication, API keys, everything like that. Once we get into the server, this is how we're interacting with the MCP server. Essentially, we have our Procore MCP server that does a lot of the

[09:45] orchestration. We have a setup, and then this is for HTTP, which would be for on-prem: if we're running the MCP locally, it would be doing the HTTP requests. We also have SSE, server-sent events. Within the registry, what we need to do is register all these tools with the MCP server, so we have our tool registry and our client factory, which is how we're provisioning those. Then we register each tool, similar to how we did with the endpoints, where we have Construction Financials here as well as Core, and then our index that leads us into these two folders. When we get into the services, the services are basically how we're

[10:30] doing the API verification and doing the request. This is essentially how we're sending the data into the Construct.Chat API, so we're able to read what those tool calls are and identify how they're functioning. We then have our tools. This is going to look quite similar as well: we have our types and our index, which leads us again into Construction Financials and Core. These are the specific subdirectories of those modules, Construction Financials specifically. Then within budgets, that directory leads us into how we're managing the definitions for those endpoints, how we're going to handle those endpoints, and then the entry point via the index. It does all of this for all of the tools within each

[11:15] of the directories here. And then we have our types, which is how we're implementing our type definitions for each of these specific endpoints that we're implementing. From there, that is really about all. I hope that you have the opportunity to implement and leverage this and get some deep insight into building intelligent construction AI agents. Thank you very much. I appreciate your time.