Oracle Primavera P6 MCP Server

[00:00] So, this weekend I spent some time developing a P6 MCP. I went through and essentially curated all of the documentation resources. I scraped their entire website for all of the help docs, as well as the API and all the resources they have available there. I also extracted the large language model text for training the model on how to develop MCPs, took the OpenAPI spec for P6, and wrote some scripts to scrape the whole website and curate it all together. From there, I developed an MCP. This MCP has a bunch of functionality that we're going to review today. So, at

[00:45] its core, the MCP is used to integrate with Primavera P6. The agents have the ability to understand and interact with the P6 API documentation. That is the enterprise EPPM, I believe. And basically it gives the agent that integration. What it does is curate all 585 REST operations and develop tools from them. It also does analysis of XER files, specific types of workflow functionality, runtime controls, and capabilities to work with organizations and teams and configure authentication for many different users, as well as how we're

[01:30] going to deploy it. So, essentially, how this works: you have your client here, and it runs through the P6 gateway runtime. This is an orchestration layer that runs through a number of different functions to map out how to interact with the API, along with different policies, restrictions, features, and capabilities, and then ultimately it sends the request to the API on Oracle's side. Up here, there is a Docker Compose sandbox, which runs the back-end system with a Postgres database and Redis for multi-tenant threading. When we go deeper, I mean,

[02:15] it basically says the same thing. There's the gateway runtime. You're leveraging a data source, which is the REST API or the XER files that are referenced. There's the capability layer, which references all of the capabilities and functionality it has access to, and then the governance layer for policies, prompting, auditing, metrics, and analysis. The capabilities are really where the MCP layer is functioning, in terms of how it performs those actions. The governance layer is how the MCP actually operates, in terms of its requirements and the rules it needs to abide by. We can dive into this, but in a

[03:00] sense, this is how the entire orchestration of the requests happens, and where requests are referenced and routed for the different capabilities within the MCP. So it goes through the features: rate limits, response cache, the policies, and then ultimately interacting with the REST API and doing the authentication. Then there are metrics, and it records all of the requests, so it can continually enhance and develop itself for the workflows and requests it uses consistently. It functions as a streamable HTTP MCP. There are some back-end systems to ensure the system is

[03:45] operating correctly, and there are metrics we can track to see what tools are being called. It runs on back-end port 8000 and uses the /mcp URL, so everything is contained under that one endpoint. In the tools catalog, there are 24 different tools specifically developed for the gateway to interact with P6. Within these, there are things like session context and discovery, so it can determine what operations it has available, and the schema for those entities. There are some specific workflows it maps to, and the ability to validate, to ensure

[04:30] that, hey, here are the endpoints we got, and to validate the plan it developed before going through and implementing those endpoints. There are of course dependencies required to make specific API requests, so it references those, and then there are specific execution operations and workflows to ensure the API requests happen, and we can resolve specific IDs. It has mutations, with the ability to preview the token and see how it will function in terms of what it has the capability to do. The request-for-approval tool is used when a policy needs to be followed: it references a specific user, who can then approve whether that request should be made or not. There's

[05:15] of course the auditing and the metrics, and there are reports and features on how each tool is being used and whether it should be included in a workflow or some higher-ranking tooling. Then there's feedback context, and specific context for the projects as well as the schedules, so it can see what schedules are available. Then there is P6 XER. This interacts with an XER file specifically, so not necessarily the API, but an XER file that can be referenced. There are 13 specific tools to work with the XER file, like parsing the file, identifying the

[06:00] activities, the critical path, resource utilization, schedule quality, various resources, and the work breakdown structure for how all of those come together, plus the relationships between the various activities, the calendars, and the schedule summary to make sure everything is working, and ultimately the earned value and activity detail. The catalog is generated ahead of time and loaded as a bundle. Essentially, there are specific operations that occur, and it's fine-tuning and prioritizing when things are generated, identifying

[06:45] sources and operations that are occurring. These are all the different metrics and how we're tracking how the tools are being used within the MCP. A bunch of metrics are recorded there in terms of what's happening, when it's happening, and all the requirements for making those requests. You can see a graph here of how it all comes together. Then, of course, there's a ranking function. When it's curating all 585 endpoints, that's a lot of context to give the agent. So what it does is take in the user's input, run it through all the workflows, policies, and operations, and then do a search to identify

[07:30] which operations it should use, and the dependencies, requirements, and fields it needs to perform that activity. Once it does that, it goes through policy to ensure that the MCP has the capabilities to perform those operations, and to determine if and when it should make those requests and whether it has the permission to do so. Then the workflow engine: these are YAML files that are loaded in. There are a few that have been created. Essentially, it's a JSON or YAML schema that identifies the workflows, the tools, the capabilities, the requirements, and the parameters for all of the workflows to

[08:15] function. These could be quite expansive and could be further developed and enhanced to add many different workflows based on the user's intent. The concept is that you start the workflow, it loads the playbook, the YAML file, and then it runs the specific operations to curate the endpoints and the required data. Then it makes sure it's running all the tools in the correct order and sequence, goes through its entire approval process, and makes sure any checkpoints, failures, or successes are recorded. These are some of the playbooks and YAML files that have been created. These can be developed,

[09:00] enhanced, or there can be many other ones. Essentially, what this does is make the selection of endpoints more intelligent. It knows what sequence of operations and which endpoints to use in the specific context needed to perform that workflow. These are some of the key flows and how they work. We talked about this before, but in a sense, the user's agent sends data into the P6 gateway. Some additional context and information is passed back and forth. It then searches the catalog and performs the request to the API. And there's the approval process that

[09:45] goes through the policy and requirements. Then this is the XER analysis. Essentially, you'd have a project, you export it, you identify the service, you get the exported file, and then that runs the XER tooling to analyze that specific XER file. There's also a hybrid of the API and XER file analysis. When a new organization is onboarded, they add their grouping, they add their P6 connection for their service, they save that connection, and ultimately they have a template that starts and connects with their MCP client, like Cursor or Claude,

[10:30] and then they can run the reports. A lot of the configuration is in back-end environment variables. These are provisioned at the organization level, and they're the data points that need to be in place for the user to interact with the MCP server, so the agent knows, "Hey, here are the specific credentials to provide when making requests to the API." These are never exposed publicly; they're only for that organization and are partitioned. Only that organization has access, and they can't be used by other organizations. And then

[11:15] that provides the authentication and identity management. There's mapping orchestration that happens in the back-end service, so no two organizations ever use the same authorization tokens or anything like that. On the back end there's also observability to identify what's being used and how it's being used, to ensure the tools are working, and to track if any APIs are updated, along with usage reports. All of that can be used for feature enhancements, further development, or implementation into specific workflows. So there are a ton of capabilities in terms of observability and

[12:00] telemetry on the back end to ensure the tooling is working properly and the MCP is working as expected. There are also some workflow templates, as we talked about, covering how resources are used, and then how we get up to speed in terms of deploying this. We deploy the Docker container, we start it, and then we have our streamable HTTP MCP available, and it's off to the races. There's a local sandbox if you want to test on a local server. Of course,

[12:45] having it on a remote server and referencing it via a streamable HTTP URL is fantastic for security and deployment. Then of course there's testing to make sure the whole thing is working properly. As the tooling and the MCP are enhanced and developed, there are specific tests the solution runs through to ensure it's working as expected, following all the security protocols, and that it will continue to orchestrate and function as expected. Then of course there's the current status and limitations of what it's capable of. But at the end of the day, it's a very robust and functional solution that has

[13:30] some additional commands here and can be used for many different use cases. So, yeah, super awesome tool. It's a great way to interact with P6 data and the API, as well as XER files. It's quite robust in terms of its capabilities and very functional. Thank you very much for your time. Really appreciate it, and talk soon. Bye.