Typestate

One blueprint's whole setup in English: every action's definition in full, the record types, web endpoints, schedules, sign-in, payments and MCP server it declares, what it cannot do, and what the person does after it starts. Read it before start_from_blueprint, and tell the person which rule they will most likely want to change.

{
  "type": "object",
  "properties": {
    "blueprint": {
      "description": "The blueprint's slug or name, as list_blueprints answers it.",
      "type": "string"
    }
  },
  "required": [
    "blueprint"
  ]
}

{
  "type": "object",
  "properties": {
    "answer": {
      "description": "The whole setup, in English, as Markdown.",
      "type": "string"
    },
    "notice": {
      "description": "Background work that did not end well since your last call. list_runs names each run.",
      "type": "string"
    }
  },
  "required": [
    "answer"
  ]
}

What Typestate is, what it costs, and how to connect to it. Call this first if you have met this server for the first time and want to know what it is for. Ask with no `about` and it answers all three parts at once. Name a `service` and it also lists what a person must do before Live works for that service (decision 0776).

{
  "type": "object",
  "properties": {
    "about": {
      "description": "Which part to answer: \"what_it_is\" for what the platform does, \"connecting\" for how an agent authenticates, \"plans\" for what it costs. Omit it to get all three.",
      "enum": [
        "what_it_is",
        "connecting",
        "plans"
      ],
      "type": "string"
    },
    "service": {
      "description": "A service slug. With it, the answer lists what a person must do before Live works for that service, one line each, with the page; hand them the list before the change.",
      "type": "string"
    }
  }
}

{
  "type": "object",
  "properties": {
    "answer": {
      "description": "The answer, in English, ready to show a person.",
      "type": "string"
    },
    "live_steps": {
      "description": "What a person must do before Live works for the service named, one line each. Empty when Live needs nothing, or no service was named.",
      "items": {
        "type": "string"
      },
      "type": "array"
    },
    "mcp_endpoint": {
      "description": "The address this server answers on.",
      "type": "string"
    },
    "notice": {
      "description": "Background work that did not end well since your last call. list_runs names each run.",
      "type": "string"
    },
    "sign_up_url": {
      "description": "Where a person opens an account.",
      "type": "string"
    },
    "website": {
      "description": "Where a person reads more about the platform.",
      "type": "string"
    }
  },
  "required": [
    "answer",
    "website",
    "live_steps",
    "mcp_endpoint",
    "sign_up_url"
  ]
}

The blueprints: whole backends for a named kind of business, each a set of English definitions proven on this platform. Ask with the purpose in the customer's words, such as "salon appointments with a deposit", before you define the first entity of a new backend. A blueprint that fits is started with start_from_blueprint, and every definition in it is the customer's own to change afterwards.

{
  "type": "object",
  "properties": {
    "purpose": {
      "description": "What the backend is for, in the customer's words. Leave it out to list every blueprint.",
      "type": "string"
    }
  }
}

{
  "type": "object",
  "properties": {
    "answer": {
      "description": "The matching blueprints, one paragraph each, in English.",
      "type": "string"
    },
    "notice": {
      "description": "Background work that did not end well since your last call. list_runs names each run.",
      "type": "string"
    },
    "slugs": {
      "items": {
        "type": "string"
      },
      "type": "array"
    }
  },
  "required": [
    "answer",
    "slugs"
  ]
}

The integration catalog: the systems a Typestate backend works with, made and checked by Typestate. A built-in one is turned on with one setting tool, which the answer names. A declared one was called against the real vendor on the date the answer gives, and apply_integration copies it into a service. Ask before you write a declaration yourself with define_integration.

{
  "type": "object",
  "properties": {
    "need": {
      "description": "What the backend needs, or a vendor's name: \"payments\", \"send email\", \"Slack\". Leave it out to list the whole catalog.",
      "type": "string"
    }
  }
}

{
  "type": "object",
  "properties": {
    "answer": {
      "description": "The matching integrations, one paragraph each.",
      "type": "string"
    },
    "notice": {
      "description": "Background work that did not end well since your last call. list_runs names each run.",
      "type": "string"
    },
    "slugs": {
      "items": {
        "type": "string"
      },
      "type": "array"
    }
  },
  "required": [
    "answer",
    "slugs"
  ]
}