MCP setup templates

Botyard's MCP catalog gives teams a repeatable way to create MCP servers without starting from a blank form every time.

The catalog can contain:

• Botyard Builtin entries maintained by Botyard, such as common server images or hosted integrations.
• Custom Templates created for your organization.
• Custom, which opens the full MCP setup form for a one-off server.

Creating from the catalog

Open MCP servers, choose a catalog entry, and review the create form before submitting it. Catalog entries prefill the same fields used by manual setup: name, description, runtime kind, image or endpoint, command, args, port, and environment variables.

Creating from a catalog entry still creates a normal MCP server owned by your organization. You can inspect it, edit supported configuration, and delete it like any other server.

Botyard also stores the catalog source name, logo, form spec version, and setup form shape on the MCP server when it is created. That lets the edit page keep showing a Snowflake-style configuration form, with the Snowflake logo and field labels, instead of reverting to raw MCP runtime settings later.

Template forms

Some catalog entries may show a smaller setup form tailored to that template. For example, a Snowflake template can ask for account, user, database, warehouse, and key material instead of exposing raw environment variables.

Those forms are compiled into the normal MCP server configuration before the server is created. This means the runtime behavior stays consistent whether the server came from a curated template or from the full Custom form.

Template JSON also declares which low-level settings are locked by the catalog entry. A locked template can hide runtime kind, image, port, transport, launch arguments, and the raw environment editor while still using those values behind the scenes. The NMAP scanner is an example: its image, port, transport, launch settings, and environment are fixed by the template, so there are no setup fields to fill in.

Plain values and secret references

For credentials and other sensitive settings, a template can let you choose how to provide the value:

• paste the value directly into the setup form
• reference an existing Runtime Vault key path

Both choices configure the same environment variable in the MCP server. Botyard stores the result in only one place:

{
  "env_plaintext": {
    "CLIENT_ID": "abc"
  },
  "env_secret_refs": {}
}

or:

{
  "env_plaintext": {},
  "env_secret_refs": {
    "CLIENT_ID": "mcp.snowflake.client_id"
  }
}

The same environment variable cannot be both a pasted value and a secret reference.

When to use Custom

Use Custom when you need full control over the MCP server definition or when no catalog entry matches what you are deploying. Custom setup exposes the full form instead of a curated template form.

npm-hosted MCP servers

Some MCP servers are distributed as npm packages and documented for local clients as npx -y <package>. Botyard can run these with the shared ghcr.io/botyard-ai/npx-mcp image, which starts the npm package over stdio and exposes Streamable HTTP on /mcp.

For a custom npm-backed server, use a container image runtime with:

{
  "image": "ghcr.io/botyard-ai/npx-mcp:latest",
  "port": 8080,
  "env_plaintext": {
    "NPX_PACKAGE": "example-mcp"
  }
}

Add any provider credentials as environment variables or secret references. For example, the Resend built-in template uses NPX_PACKAGE=resend-mcp and maps your API key to RESEND_API_KEY.

For catalog templates, set runtime_kind: npx. Botyard still creates the server as a container-image MCP under the hood, using the shared npx-mcp image and the same provisioner path as bespoke wrappers.