This page is for the admin. It explains MCP servers and skills on the gateway, what to watch out for, and how they reach agents like Hermes and Claude Code.

​
The two ideas

Both live in the gateway’s database. The gateway controls which keys can reach which MCP server, and which skills exist.

​
An example MCP server: context7

A common first MCP server is context7, which gives a model current documentation for libraries and frameworks. When a model needs to know how a library works today, it asks the server instead of guessing from its training data.

​
How an agent reaches an MCP server

The gateway speaks the MCP protocol over HTTP. An agent that supports MCP — Hermes, Claude Code and others — can connect to the gateway’s MCP endpoint and discover the available servers.
1

Check the agent supports MCP

Hermes and Claude Code both support MCP clients. The agent connects to a server URL and lists its tools.
2

Point the agent at the gateway

The gateway exposes MCP discovery under the model API. The agent authenticates with a gateway key.
3

Approve the tools

The agent lists the MCP server’s tools and asks whether to use them. Only grant what the task needs.
4

Use the tool

When the model calls the tool, the request goes agent → gateway → MCP server → back.
An MCP server is code that runs somewhere else and returns content. A model will treat that content as ground truth. Only connect MCP servers you trust, and review what tools they expose before you let a key reach them.

​
Adding an MCP server

1

Open the admin UI

Go to https://llm.hjc925.cloud/ui and sign in.
2

Open the MCP section

Find MCP servers in the admin pages.
3

Register the server

Give it a name, the transport (HTTP or command), and the address or launch command.
4

Set access

Decide which keys or teams may reach it. Leaving access groups empty lets any key use it.
5

Review the health check

The gateway checks the server and reports status. A failing server shows its error.

​
What to look out for

The MCP server may have many tools. The agent decides which to offer the model. Fewer, well-chosen tools beat a long confusing list.
Some MCP servers need their own credentials (API keys, OAuth). Those credentials are stored on the gateway, per user, not in the model’s context. Treat them like any other secret: never paste one into a chat or a file in this folder.
A remote MCP call adds network time, like any API call. The gateway health-checks servers so a dead server shows up instead of failing silently.
A skill file tells the agent how to do a task. It does not constrain the model’s other behaviour. Load skills you wrote or reviewed, for the same reason you review MCP servers.

​
Skills

A skill is a stored file: a title, a description, and instructions. The gateway stores skills in its database so they are available to agents that connect.
1

Create the skill

In the admin UI, add a skill with a title, description and instructions.
2

Keep instructions tight

One task per skill. Write the steps so an agent can follow them without guessing.
3

Test it

Load the skill in an agent and check the output matches the instructions.
4

Review it like code

A skill is executable guidance. Treat edits to it with the same care as edits to code.

​
The agent-side story (Hermes and Claude Code)

The gateway holds the tools (MCP servers) and skills. But the agent that uses them also has its own configuration.
  • Hermes has its own skills and tools installed locally. It can also reach the gateway’s MCP servers as a client.
  • Claude Code connects to the gateway through ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. It can use MCP servers the same way it uses any MCP host.
The important split: The gateway is the shared, central layer. The agent’s local setup is the personal layer. Both can feed a model tools; they are not the same thing.
Do not paste a gateway API key into a prompt, a file in this repo, or a chat transcript. Keys are handed out by the Access Manager and stay out of files.