Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.atlasmeets.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Purpose

The manifest tells Atlas what the gateway can do. It should be stable, explicit, and machine-readable.

​
Top-level shape

{
  "version": "2026-03-18",
  "gateway": {},
  "agent": {},
  "actions": [],
  "callbacks": {
    "jobResults": true,
    "approvals": true
  }
}

​
Gateway metadata

The gateway object should describe:
  • id
  • name
  • url
  • optional description
  • auth mode
  • high-level capabilities such as async jobs, callbacks, and approvals

​
Agent metadata

The agent block is descriptive metadata from the customer side. It can identify the internal system or capability layer behind the gateway, but it is not an Atlas agent definition.

​
Actions

Actions are the actual callable units. Each action should expose:
  • optional id
  • name
  • optional title
  • description
  • executionMode
  • inputSchema
  • optional outputSchema
  • optional outputDescription
  • requiresApproval
  • sideEffectLevel
  • idempotent
  • optional timeoutMs
  • optional scopes
  • optional tags

​
Schema guidance

Keep the schema subset simple and provider-safe. Good:
  • type
  • properties
  • required
  • items
  • enum
  • additionalProperties
Avoid in v1:
  • $ref
  • oneOf
  • anyOf
  • deep schema indirection

​
Strict-safe input schemas

Atlas is moving toward exposing gateway actions as first-class typed tools whenever the manifest schema is clean enough. That works best when action inputSchema follows a strict-safe shape:
  • root schema is always an object
  • additionalProperties: false
  • include required: [] even for no-input actions
  • if a field is optional, prefer a nullable required field instead of omitting it from required
Examples: No-input action: 
{
  "type": "object",
  "properties": {},
  "required": [],
  "additionalProperties": false
}
Optional field, strict-safe: 
{
  "type": "object",
  "properties": {
    "date": {
      "type": ["string", "null"],
      "description": "Optional report date in YYYY-MM-DD format."
    }
  },
  "required": ["date"],
  "additionalProperties": false
}
This keeps the manifest easy for coding agents to generate and easier for Atlas to turn into robust tool calls.

​
Example action

{
  "name": "lookup_customer",
  "title": "Lookup Customer",
  "description": "Return a compact customer profile from the internal CRM.",
  "executionMode": "sync",
  "inputSchema": {
    "type": "object",
    "properties": {
      "email": { "type": "string" }
    },
    "required": ["email"],
    "additionalProperties": false
  },
  "requiresApproval": false,
  "sideEffectLevel": "read",
  "idempotent": true
}