Creating Servers

A server in Airlock represents an API or service you want to expose to AI agents through the MCP protocol.

Server Types

Airlock supports several server types:

Type	Description	How to Create
Pre-built Integration	Proxy to an upstream MCP server (GitHub, Linear, Notion, etc.)	Select from the integrations list
Custom OpenAPI	Any REST API with an OpenAPI spec	Paste your OpenAPI spec
Knowledge Graph	Per-organization graph store for entities and relationships, queried via the memory_* tool family	Select "Knowledge Graph" type
Airlock Code	Index your GitHub repositories and let agents query architecture, call graphs, in-repo and cross-repo references	Select "Airlock Code" type and install the GitHub App

Creating a Server

From the Control Room

1. Navigate to MCPs in the sidebar
2. Click New MCP
3. Choose a server type

Pre-built Integrations

Select from 50+ pre-configured integrations. These come with tools already defined — no OpenAPI spec needed. See Pre-built Integrations for the full list.

Custom OpenAPI Server

For custom REST APIs:

1. Enter a Name for your server
2. Paste your OpenAPI Specification (YAML or JSON)
3. Enter your Target URL (the base URL where Airlock sends requests)
4. Click Create

OpenAPI Specification

Airlock uses OpenAPI specifications to understand your API's structure:

openapi: 3.0.0
info:
  title: My API
  version: 1.0.0
servers:
  - url: https://api.example.com
paths:
  /users:
    get:
      operationId: list_users
      summary: List all users
      responses:
        '200':
          description: List of users
    post:
      operationId: create_user
      summary: Create a new user
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                name:
                  type: string
                email:
                  type: string

Operation IDs

Each operation in your OpenAPI spec must have an operationId. This becomes the tool name in MCP:

• operationId: list_users becomes a tool called list_users
• operationId: create_user becomes a tool called create_user

Knowledge Graph Server

A Knowledge Graph server is a per-organization graph store for entities and the relationships between them. It comes pre-wired with the memory_* tool family — search, get/explore entities, link/archive/delete, batch create, schema introspection, and natural-language graph queries.

To create one:

1. Click New MCP and select Knowledge Graph
2. Give it a name and click Create

The schema is layered — entities live in one of four layers (semantic, temporal, procedural, code) with conventional types like Person, Project, Document, Event, Decision, and Workflow. The schema grows on demand: when an agent writes a new PascalCase entity or relationship type, it's registered automatically. You do not need to seed types up front. Storage is backed by Parquet files on S3 and queried with DuckDB — you do not need to run or manage any database yourself.

Airlock Code Server

An Airlock Code server indexes one or more of your GitHub repositories and exposes them to agents as a queryable code-intelligence surface. Agents can ask questions like "which functions call chargeCustomer?", "what's the call graph for the checkout flow?", or "who depends on this module across repos?" without you writing any tools.

To create one:

1. Click New MCP and select Airlock Code
2. On the server detail page, install the Airlock Code GitHub App to grant read access to your repositories
3. Choose which repositories to track — indexing kicks off automatically

The first sync takes a few minutes for typical repositories; subsequent updates run incrementally on every push. The Repositories tab on the server detail page shows sync status per repo and lets you trigger a manual re-sync.

Server Configuration

Target URL

The target URL is where Airlock sends requests. This can differ from the URL in your OpenAPI spec:

• OpenAPI servers[0].url: Documentation/design time URL
• Airlock Target URL: Runtime URL for actual requests

This allows you to:

• Use different environments (staging, production)
• Route through internal networks
• Add path prefixes

Authentication

Each user connecting to a server provides their own API credentials:

• OAuth: For services that support OAuth flows (GitHub, Google Calendar, etc.)
• API Key / Bearer Token: For services that use static credentials

See Authentication for details.

Syncing Tools

After updating an OpenAPI spec or when upstream MCP server tools change, use the Sync Tools button on the server detail page to refresh the available tools list.

Managing Servers

Editing

Click on a server to view and edit its configuration:

• Update the OpenAPI specification
• Change the target URL
• Modify policies
• Manage user credentials

Deleting

1. Click on the server to open the detail page
2. Scroll to the bottom of the page (admin access required)
3. Click the Delete Server button

WARNING

Deleting a server removes all associated policies, access tokens, and pending requests.

Best Practices

Operation Naming

Use consistent, descriptive operation IDs:

# Good
operationId: list_orders
operationId: get_order_by_id
operationId: create_order

# Avoid
operationId: op1
operationId: getOrder  # Inconsistent casing

Security

• Never include credentials in the OpenAPI specification
• Use HTTPS for all target URLs
• Regularly rotate API credentials