Skip to main content
The MCP Store is a fixed MCP endpoint every gateway serves at https://<mcp-host>/store/mcp. A person points their MCP client at it, signs in with their NeuralTrust login, and gets three gateway tools to search the whole NeuralTrust MCP catalog, install a server for themselves, and remove it. The tools of everything they installed appear on that same URL. The Store is for people; consumers are for applications. A consumer’s surface is exactly the registries an admin bound to it and is the same for every caller it admits. The Store’s surface is per person: what they installed, bounded by their Access level and grants. Neither governs the other. The console shows the URL under the gateway’s settings as MCP Store (Copy MCP Store URL). Employees without console permissions reach the same catalog through the Portal.

​
Connect from a client

Any client that supports streamable HTTP with OAuth works the same way; see Connect an agent. The sign-in is the built-in NeuralTrust login for the gateway’s organization; on NeuralTrust-hosted gateways a session from another organization is rejected.

​
Store tools

An install result always carries code, name, status, pending, already_installed, requires_auth, requires_config, requires_admin_setup, and config_variables (null when the server needs no setup values). The flags tell the agent what happens next: Tools from a per-instance install, and from any Store with more than one server, are published under the federated naming scheme described in Tool name composition.

​
Store mode

The gateway’s store_mode is the default level for everyone on that gateway. Set it with PUT /v1/gateways/{id} or on the Access page as Default access: A per-user or per-group level set on the Access page overrides the gateway default; the effective level is re-evaluated on every request, not only at install time.

​
Per-user accounts and setup values

Installing a server creates or reuses one shared registry per catalog code on the gateway. What is per person lives elsewhere:
  • Accounts. A forwarded-auth server stores each person’s OAuth credential in the vault under their principal, keyed by provider and instance. Two people installing the same server never share a credential. Until they connect, the server shows as needs_connect in trustgate_list_tools and contributes no tools.
  • URL variables. Servers such as Snowflake or ServiceNow build their URL from values only the user knows. Plain values ride on the installation; secret values are stored in the vault, entered only on the hosted configure form.
The Store’s tools/list answers an empty list plus the gateway tools while a registry is unconnected or nothing is installed yet; it never fails the handshake.

​
Instances

A multi_instance catalog server can be connected more than once with different configuration (two Snowflake schemas, two API keys); admins add them from the registry side panel (Instances → Add instance). When several exist, the Store asks the user which one to install or uninstall. See Instances and the Store.

​
Requests and approvals

When a person’s level is Selected and the server is not granted to them, the install becomes a request carrying the reason they wrote (up to 500 characters) and the groups they belonged to when they filed it. Admins decide it in Access → Approvals; approving grants the server to the person or to one of their groups, so the next install is instant.
  • Access: levels, grants, approvals, and admin preview
  • MCP Gateway: meta-tools, forwarded auth, and tool naming
  • Registries: instances, origin: "store", and from-catalog