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"
    }
  },
  "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.

{
  "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"
    }
  }
}

{
  "type": "object",
  "properties": {
    "answer": {
      "description": "The answer, in English, ready to show a person.",
      "type": "string"
    },
    "mcp_endpoint": {
      "description": "The address this server answers on.",
      "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",
    "mcp_endpoint",
    "sign_up_url",
    "website"
  ]
}

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"
    },
    "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"
    },
    "slugs": {
      "items": {
        "type": "string"
      },
      "type": "array"
    }
  },
  "required": [
    "answer",
    "slugs"
  ]
}