[00:00] Hello everyone, and welcome back to N3uron Academy. In the previous videos of this MCP Server series, we introduced the Model Context Protocol, configured the server, and connected different MCP clients to our N3uron node. In this video, we are going to focus on MCP Server tools: how the built-in tools are exposed, how access is controlled, and how we can create, troubleshoot, and test our own custom tool from beginning to end. As in the previous videos, we are going to use the AI-Ready PV Demo as our working environment. If you want to follow the tutorial, you can request this backup project from N3uron and restore it on your own node. The idea is to give you a complete environment for learning and testing MCP Server without having to connect to a real plant. Everything required to get started is documented in our Knowledge Base. The project represents a simulated photovoltaic plant, but the simulation is driven by data taken from a real PV installation.

[01:02] It provides live values, historical data, alarms, a structured industrial tag model, and a complete Web Vision HMI project for visualization. This means that, even though we are working in a safe demo environment, we still have realistic plant behavior and enough operational context to test how an AI client interacts with N3uron. Before moving into the tools, there is one update compared with the earlier videos in this series. Since N3uron version 1.22.4, MCP Server includes OAuth 2.0 support, together with settings for the maximum number of concurrent sessions and the session idle timeout. These additions give us better control over MCP client connections, especially when the server is being accessed remotely or by hosted AI services. Very briefly, OAuth 2.0 is an authorization framework. It does not replace the permission model we configure in N3uron, and OAuth itself is not a user-authentication protocol. In this N3uron flow, the long-lived N3uron API token represents the principal and carries the permissions we configure in MCP Server.

[02:02] During authorization, that API token is entered on the N3uron consent page and remains on the N3uron side. The remote MCP client receives a short-lived OAuth access token and a refresh token. When the refresh token is used, a new token pair is issued and the previous refresh token is invalidated. For a hosted or remote client, the OAuth issuer must be reachable through a public HTTPS address. This can be provided by a reverse proxy, a public gateway, or, for a temporary lab setup like this one, a secure tunnel. I do not have a public address available for this recording, so I am using ngrok. It runs on the host machine and exposes a public HTTPS endpoint that forwards traffic to the local N3uron HTTPS listener. In this example, the public TLS connection terminates at ngrok, and ngrok forwards to N3uron over HTTPS as well, so both network legs are protected by TLS. More information about the OAuth configuration and the complete authorization flow is available in our Knowledge Base.

[03:22] For this tutorial I am using MCPJam. MCPJam is a very convenient MCP testing environment, and it is especially useful when we want to inspect and execute custom tools directly before involving an AI model. Here, we add the public tunnel endpoint as the MCP Server address. MCPJam reaches the server, discovers the OAuth metadata, and starts the authorization flow. N3uron then presents the consent page, where I provide the N3uron API token associated with the access profile I want to use.

[04:06] After consent, the client exchanges the authorization code for its OAuth access and refresh tokens and completes the MCP connection. From this point on, the client uses the derived OAuth access token when it sends requests to the MCP endpoint. The original N3uron API token is not exposed to the remote MCP client. Once the MCP session is established, MCPJam can discover only the tools, prompts, resources, and tag paths that are permitted by the N3uron access profile behind that authorization. Now let us look at that access configuration. We can create different access tokens for different users, applications, or roles, and each one can expose a different capability set. As a general rule, it is sensible to grant only the permissions that a client actually needs. In this example we are focusing on tools, so we allow Custom Tools access and enable read access only for the built-in categories we want to use.

[05:00] We do not have a redundancy configuration in this demo, so Redundancy can remain set to None, and the same principle applies to Links, write operations, or any other capability that is not required. N3uron provides more than forty built-in MCP tools, grouped into ten categories. Each category includes inline help with a short explanation of the available operations and their arguments, while the Knowledge Base contains the complete reference. In the Tools section we can also see the custom tools already included in the AI-Ready PV Demo. These are tailored to this project and give us a useful starting point for understanding how custom tools are structured. Before we create one, let us summarize the concept with a few slides. First, an AI agent connects to N3uron MCP Server and discovers the capabilities exposed by the access profile. The model can then select a tool by name, provide the required arguments, execute it through MCP, and use the returned structured result as additional context. Second, there are two tool families. Built-in tools are ready-made, general-purpose capabilities supplied by N3uron.

[06:02] Custom tools are operations that we design for a particular use case and implement through the Scripting module. Third, custom tools are especially valuable for repeatable domain operations. They let us package deterministic logic, combine information from different parts of the node, use terminology that belongs to our process, and expose the same operation consistently to different AI clients. Fourth, a custom tool has two clearly separated parts. The MCP Server Tool configuration is the interface, or contract, that the client sees. It defines the tool name, description, input schema, output schema, and the linked Scripting Method. The Scripting Method is the implementation that actually runs. Its input arguments arrive through the dollar dot event object, and the value returned by the Method becomes the tool result. Fifth, the Method is not limited to simple calculations. It can use the N3uron API through dollar dot API, standard JavaScript capabilities, N3uron libraries through dollar dot lib, shared libraries, and external NPM packages when required. And finally, you do not have to design every custom tool completely by hand.

[07:02] N3uron Agent Skills can provide an AI agent with N3uron-specific guidance for designing the contract, writing the linked Method, and working with the wider platform. You can download the N3uron Agent Skills and use them with a compatible AI assistant. We have a dedicated article in the Knowledge Base explaining how to install and use them. Here I am showing a simple example with ChatGPT, where the N3uron skill has already been added. Instead of describing every configuration field myself, I can explain the outcome I want: for example, a tool that checks whether the two inverters in a selected power station are producing a similar amount of active power. The assistant can then guide the design of the Method, the inputs and outputs, and the MCP Tool configuration using the N3uron-specific context provided by the skill. This is useful when you are creating more complex integrations or when you want a starting point that follows the N3uron architecture. For this particular video, however, we are going to create the tool manually so that we can see each part of the mechanism ourselves. We start in the Scripting module.

[08:00] Inside the existing MCP Custom Tools hierarchy, we open the Operations action, which is configured as a Method action, and create a new Method called ops check station inverters balanced. A Method does not execute on a timer or on a tag change. It waits for another N3uron module to call it, and in this case the caller will be MCP Server. We enable it, keep Method access at Read, configure the input and output to accept JSON data, and leave the worker inactivity timeout at ten thousand milliseconds. Now we open the script. The most important object to understand is dollar dot event. This object contains the arguments sent by the MCP Tool. Our script reads the selected power-station number and the configured threshold from that object, validates the input, and then builds the corresponding BLUELAKE tag path. The power-station number is formatted as PST underscore zero one through PST underscore ten, and from that base path we read the ACTIVE POWER tag for INV zero zero one and INV zero zero two.

[09:00] The reads are performed with the N3uron Scripting API using dollar dot API, tag read. Once we have both live values, the script converts them to numbers, validates the results, calculates the absolute difference between the two inverter powers, and decides whether that difference is inside the configured threshold. Finally, the Method returns a JavaScript object containing the station, both active-power values, the calculated difference, the threshold, and a Boolean balanced result. That return object is important because it is what MCP Server receives from the Method and sends back as the custom-tool result. If you want to explore other calls available to Scripting, the Scripting API section of our Knowledge Base documents tag reads, history, alarms, system calls, and the rest of the available API. With the implementation ready, we move to MCP Server and create the public tool interface. This is the part that the MCP client, and therefore the AI agent, can discover. We enable the tool, assign a unique name and a clear human-readable title, and write a description that explains what the tool does and when it should be used.

[10:03] Then we select the Scripting module instance and use the Method browser to link the Method we just created. This browser is useful because it avoids having to type the Method path manually and makes the relationship between the tool and the Scripting implementation explicit. Next we define the input schema. In our case, the client needs to provide a power-station number and a threshold value. Each input has its own data type, description, nullable setting, required setting, and, when useful, a default value. We configure defaults here so MCPJam can execute the tool immediately with a known starting point. Then we define the output schema. The output describes the object that we expect the Method to return:

[11:44] The station identifier, the active power of each inverter, the calculated difference, the threshold used for the comparison, and the final balanced state. Think of these schemas as the contract between the MCP client and our implementation. The input schema tells the client which arguments it can send.

[12:00] The output schema tells it which structured fields it can expect back. The actual logic still runs in Scripting, but the schema gives the AI model a machine-readable description of how to call the operation and how to interpret the response. Once the tool configuration is complete, it is a good idea to enable the MCP Server diagnostics while we test. Custom tools involve several layers, so diagnostics make it much easier to see whether a problem occurs in the MCP request, the Method invocation, or the script itself. We now return to MCPJam, refresh the connection, and open the Tools section. Our new custom tool is visible together with its description, input schema, output schema, and the argument fields generated from that contract. Because we configured default values, we already have a convenient set of inputs for the first test. We execute the tool directly, without an AI model in the loop. And this is exactly why testing the tool directly is useful: the first execution fails. At this point we know that discovery is working, because MCPJam can see the tool and build its input form.

[13:02] We also know that the request reaches MCP Server. The failure is happening further down the execution path. Rather than guessing, we go back to N3uron and inspect the diagnostics. The MCP Server log shows that the custom tool call reached the linked Scripting Method, but the worker terminated while the Method was running. That gives us a much smaller area to investigate. When we compare the MCP Tool contract with the Method code, we find more than one mismatch. One of the input argument names used by the tool does not match the property that the script initially expects, and some of the property names returned by the script do not match the output schema we configured in MCP Server.

[14:03] This is an important lesson when building custom tools: the contract and the implementation must agree exactly on the argument names and the returned structure. The values arrive in Scripting through dollar dot event using the names defined by the MCP input schema, and the returned object must expose the fields described by the output schema. We correct those names, align the return object with the tool contract, save the changes, and restart the affected Scripting and MCP Server modules before testing again. Restarting the modules also ensures that the runtime is using the latest Method and tool configuration. Now the execution path is consistent from the MCP client, through MCP Server, into Scripting, and back to the client.

[15:05] Back in MCPJam, we run exactly the same custom tool again. This time the request succeeds and MCPJam confirms that the structured content matches the output schema. We can see the selected station, the current active power of both inverters, the difference between them, the threshold used for the check, and the final balanced result. We can also compare those values with the N3uron real-time data to verify that the tool is reading the expected tags. Once the first test is correct, we repeat the call with other power stations. Here, for example, we select Power Station 3 and the Method automatically resolves the corresponding PST zero three inverter paths. This is the main benefit of packaging the logic as a custom tool: the client provides a small, well-defined set of arguments, while the N3uron-side Method handles the deterministic tag-path construction, live data access, validation, and comparison logic. After validating the tool directly, we can use another useful MCPJam feature:

[16:02] The Playground, where we can test the same MCP connection with different AI models. We give the model a simple request to check the inverter balance in Power Station 3 of the BLUELAKE PV Plant using the n3remote MCP Server. The agent can see the tools exposed by that connection, selects our new custom tool, builds the arguments, executes it, and then interprets the returned values for the user. From there, the result could be combined with other tools, documents, plant context, or additional reasoning according to the agent’s permissions. The possibilities are very broad. As always, visit the N3uron Knowledge Base for the complete MCP Server, Scripting, OAuth, and custom-tool documentation. Thanks for watching. Take care, and see you in the next N3uron Academy video.