Connecting an MCP Client to MCP Servers on a Neuron

The following list outlines the steps necessary to connect an arbitrary LLM AI Agent with support for the Model Context Protocol (MCP) to a Neuron®, and allow the agent to use the MCP Servers published by the Neuron. In this interoperation, the LLM Agent will act as an MCP Client, and the Neuron will host multiple MCP Servers, as this specific type of web services are called. These MCP Servers can be integrated with the Neuron itself, or be published by pluggable modules installed on the Neuron. For a list of MCP Servers available in the Neuron itself, see the API section, MCP subsection in the Neuron Documentation.

1. The first step is to register the LLM MCP client with the Neuron. This can be done manually, by creating a User Account, or XMPP Account on the Neuron (both types can be used). This can also be done, as recommended by the Model Context Protocol itself, and its HTTPS binding, by using OAUTH2. If registering the client dynamically using OAUTH2, an XMPP account will be created for the client under the hood. The account will have no privileges by default.

2. Regardless of which route is selected, the user account or XMPP account need to be assigned a corresponding role. An appropriate Role has to be defined first, if none exist. Access to MCP servers is authorized. Each MCP Server lists the privileges different features require in its documentation. MCP and OAUTH2 scopes are translated to required privileges in the Neuron. Each Role defines what privileges it has. And a User or XMPP account having a specific role has by extension the privileges held by any of its roles.

3. Once the LLM Client is registered with the Neuron, and relevant privileges have been assigned, the MCP Client needs to connect to one or more MCP Servers. This is done by configuring the MCP Servers it has access to. The LLM Client then authenticates itself with the Neuron using OAUTH2 (or other available mechanism), and then connects to each MCP Server in turn. For a list of MCP Servers available on the Neuron, see the Neuron Documentation.

4. For troubleshooting, Postman can be used to interact with the MCP Servers on the Neuron as well. Similar steps as mentioned above has to be taken with Postman, with the exception that Postman cannot register itself dynamically. An account has to be created manually on the Neuron first. Postman can then connect using OAUTH2, generating an access token that can then be used to access the different MCP Servers.

#tutorial, #mcp, #ai, #oauth

OAUTH 2 support in the Neuron

The Neuron® now supports OAUTH 2.0, and can be used as an authorization server in OAUTH-compliant systems (from build 2026-07-13). The OAUTH 2 environment available in the Neuron includes the following resources:

• An authorization resource (RFC 6749) at /oauth/authorize.
• A token resource (RFC 6749) at /oauth/token.
• A dynamic client registration resource (RFC 7591 and RFC 7592), supporting both public and confidential client registrations, at /oauth/register.
• A management resource for dynamic client registrations (RFC 7591) at /oauth/registration.
• A resource providing support for the device authorization flow (RFC 8628) at /oauth/device
• A token introspection resource, in accordance with RFC 7662 at /oauth/introspect
• A server OAUTH meta-data resource (RFC 8414) at /.well-known/oauth-authorization-server allowing external parties a way to find available resources and features.
• A resource providing meta-data for protected resources (RFC 9728) at /.well-known/oauth-protected-resource.

Apart from the resources defined, there are some notable features and extensions that are supported, and merit mentioning:

• Proof Key for Code Exchange by OAuth Public Clients (PKCE) (RFC 7636), securing the authorization flow.
• Support for refresh tokens (RFC 6749)
• Implicit token generation from traditional Neuron authentication, or Mutual TLS (mTLS).
• OAUTH clients (services) that want to use the Neuron as an OAUTH authorization server, should register themselves with the Neuron using the dynamic client registration interface, and provide a human-readable name, logotype and corresponding URIs for more information.
• Dynamic login forms generated by the OAUTH environment are generated first in Markdown, and then transformed to HTML before being returned to the user. This allows opertors of the Neuron to customize the look & feel of the login form, by customizing the MasterOAuth.md file available in the web root folder. The dynamic form is embedded in this master file, before being rendered as HTML.

Authentication, scopes and privileges are related as follows:

• Scopes in OAUTH, are translated into Privileges in the Neuron, having the prefix OAUTH.Scope. followed by the scope, where colons (:) are replaced by periods (.).
• An external party can authenticate itself with the OAUTH environment, and be authorized to receive a JWT token, which it should provide in subsequent requests using a Bearer token in an Authorization HTTP header.
• Dynamic client registrations, and clients that authenticate themselves using credentials for an XMPP account, have no privileges by default. Attempts to authorize access to specific scopes using such accounts will be rejected.
• Administrative user accounts will have the privileges provided to them via the Roles defined for the corresponding user accounts.

Dynamic client registration has been integrated into the Neuron using the following principles:

• The Neuron enables dynamic client registration by creating an API Key with the name OAUTH. If there is no such API key on the Neuron, dynamic client registration is not permitted.
• A remote endpoint can register at most 2 clients (public or confidential).
• Registered clients receive a corresponding XMPP account with the same client_id. These accounts are disabled for XMPP communication by default, but can be enabled manually. (Future work may provide a mechanism to automatically enable such accounts, by validating e-mail and/or phone numbers provided in client registration.)

Security Note: You can limit access to OAUTH using the Web-Application Firewall (or WAF), by restricting access to any resource that starts with /oauth/.

#new, #features, #neuron, #api, #oauth, #security