Create and Deploy Your Own MCP Server on Adios

Build path

Treat the MCP server like a small, inspectable backend.

The first version should be boring: a clear process boundary, a small set of tools, predictable config, and enough logs to debug client calls.

Pick the production transport

Desktop MCP servers often start with stdio. A hosted MCP server should expose an HTTP-compatible transport, a health route, and a stable HTTPS URL.

Define narrow tools

Start with a small set of tools that map to real product actions. Give every tool a clear input schema, validation, timeout, and error shape.

Keep credentials out of source

Store provider keys, database URLs, webhook secrets, and OAuth client secrets as Adios secrets, then reference them from adios.yaml.

Run it like an API

Add build, start, and health commands. Test the MCP route locally, check logs, and make sure unhealthy dependencies fail readiness.

Deploy and connect clients

Deploy the server to Adios, attach a route or custom domain, and point compatible MCP clients at the production URL.

Project layout

Keep protocol code, tools, auth, and deploy config separate.

package.json

Runtime dependencies, scripts, and MCP SDK adapter.

src/server.ts

HTTP server, MCP transport adapter, tools, and resources.

src/tools/*.ts

Small tool handlers with input validation and timeouts.

src/auth.ts

Optional bearer token, OAuth, or signed-request checks.

scripts/healthcheck.js

Readiness probe used by Adios.

adios.yaml

Build, start, port, health, region, and secret references.

adios.yaml

Deploy the MCP server with explicit runtime commands.

This example assumes a Node or TypeScript MCP server that exposes an HTTP transport on `PORT`. Use the same pattern for Python, Go, or another runtime.

Read manifest reference Follow quickstart

name: product-mcp-server
region: de

build_cmd: npm ci && npm run build
start_cmd: node dist/server.js

runtime:
  name: node@24
  port: 8080
  health_path: /healthz

secrets:
  MCP_AUTH_TOKEN: secret://MCP_AUTH_TOKEN
  DATABASE_URL: secret://DATABASE_URL
  PROVIDER_API_KEY: secret://PROVIDER_API_KEY

Development loop

Build locally, then verify through the deployed route.

Local tool tests

Call each tool handler with valid and invalid input. The server should return structured errors, not stack traces.

Preview on Adios

Deploy a preview, check runtime logs, and verify the health endpoint before connecting real clients.

Production rollout

Attach the final route, rotate secrets through Adios, and keep future tool changes behind the same deploy flow.

FAQ

Custom MCP server questions.

Should my hosted MCP server use stdio?

No for production hosting. Stdio is useful for local desktop integrations, but a hosted server should expose an HTTP-compatible transport and a health route behind HTTPS.

Can I deploy a TypeScript or Python MCP server?

Yes. Adios runs normal long-lived app processes. Use the runtime and start command your MCP server needs, then expose the configured port.

How should I protect MCP tools?

Treat MCP tools like API endpoints. Validate inputs, require scoped credentials, set timeouts, avoid broad admin tokens, and keep secrets outside source.

How is this different from the Adios MCP platform page?

This guide is for building and deploying your own MCP server. The /mcp page explains how to use Adios itself through the Adios MCP endpoint.