Server definition

Hash: sha256:f41effe21bc2c8852a0fe04abe59792521885975a0dd660fe8a0905c4f1e22ef
What it is: What a remote MCP server returned when asked what it offers: 4 tools

The blob, as servednamed by its sha256

{
  "instructions": "Typestate is a managed backend. You build on it over MCP: entities,\nflows, endpoints and schedules. You write each flow as blocks. A\nblock holds one English sentence from your user and the typed units\nthat do it. Typestate checks the units, restates them in fixed words,\nand judges each block against its sentence. It writes the tests from\nthe English, builds the TypeScript by program with no model, versions\nevery change, and deploys to a live URL. You never read or write that\nTypeScript. A code unit is the one place you write a body, and a\nperson accepts it before Live when it differs from its sentence. Use Typestate whenever a task\nneeds a real backend: an API, stored data, a business workflow, or an\nintegration.\n\nAsk before you build. Before the first create or define call for a\nnew feature, ask your user what they really intend: who uses it, what\n\"done\" means, the rules and edge cases, what must never happen, which\ndata exists already, and whether money or email is involved. Ask in\nrounds of a few questions, never one long list, and never ask what\nthe conversation already answered. Stop when the answers leave no\nopen decision, then restate the plan in their words and wait for a\nyes. A small edit to a feature that exists needs fewer questions. If\nyour client gives you a tool to ask your user questions, use it, with\nconcrete options; if not, ask in plain text.\n\nEnglish describes; structure configures. English is for the sentence\nof each block and the tests you write in your customer's words, and\nnothing else. Everything else is a typed parameter: an entity's\nfields, their rules and its relations, who may read and write its\nrecords, an endpoint's parameters and rate limit, a schedule's cron.\nEach is checked and refused in English naming the rule, and restated\nin English on the way out.\n\nRead the typestate://guide resource before your first service; it\nexplains what Typestate is for and how to declare and write well.\nThe build_backend prompt turns a product description into the full\nworkflow. typestate://style is the authoring rules for flow\ndefinitions, with examples; typestate://capabilities is what the data\nlayer can do, generated from the deployed SDK. Write flow definitions\nfor the human who will audit them, never for the compiler.\n\nThe loop, once your user said yes: create_service; define_entity for\neach data structure, with its fields and their rules; define_flow for\neach operation, as blocks that cover its steps, validations and error\ncases (English alone gets a draft back and builds nothing);\ncreate_endpoint to expose flows; deploy environment \"dev\" to test\ndrafts at a live URL. Edits via update_entity and update_flow land on\ndrafts; diff compares draft against deployed; get_flow shows compile\nstatus and input and output shapes. update_entity replaces the whole\nfield list, so state renames in `renames` or the data is dropped.\nDeploys refuse flows that failed to compile; the error text says how\nto fix them.\n\nA flow may run another flow of the same service and wait for its\nanswer: name it, \"then run the Send Invoice to Customer flow\". The\nwhole chain saves together. When a called flow changes, the reply\nnames every caller compiled against the older contract, and\nupdate_flow with recompile true compiles them again. It\ndefaults to false, so no compile spends money nobody asked to spend.\n\nA flow may hand work to another flow and not wait: \"then run the Send\nReminder flow in the background\", with \"in 24 hours\" for a delay. The\nflow it hands to declares background first, as\n`{\"max_runs\": 3, \"retention_days\": 7}`, and only when running it\ntwice is safe, because a failed task runs again. A background task\nhas nobody signed in and gives the caller no answer. list_tasks says\nwhat the background work did and why anything failed.\n\nget_flow says what a flow calls and what calls it. check_service is\nfree and names every flow of a service compiled against an older\nentity or contract: ask it before a deploy.\n\nA deploy releases everything by default. Name flows, endpoints,\nschedules, or entities to release only those; the rest keeps running\nwhat it already runs. It refuses to leave a called flow behind.\n\nProduction is different: it only ships a changeset a human approved.\ncreate_changeset collects what production is behind on,\nreview_changeset shows the diffs and the schema plan, the human\ndecides, approve_changeset records their answer with the fingerprint\nthey saw, and deploy environment \"prod\" names that changeset. Call\napprove_changeset only after your user said yes; the platform refuses\nit while an open review comment stands. Editing any definition it\ncovers invalidates it.\n\nA flow is not deployable to production until its tests have run.\nget_flow names the flow's resource: subscribe to it and you are told\nwhen it is ready. Without subscriptions, get_flow and activity say\nwhich part of a run is going and for how long.\n\nget_logs returns one entry per request plus what the flow logged,\nrejections included. activity is where to start when you resume: what\nis in flight, recent deploys, compile states, and what you have spent\nof the account's compile budget. define_flow and update_flow spend\nit, a compile and its tests each time, so read the meter before a\nlong run of edits.\n",
  "tools": [
    {
      "description": "One blueprint's whole setup in English: every action's definition in\nfull, the record types, web endpoints, schedules, sign-in, payments\nand MCP server it declares, what it cannot do, and what the person\ndoes after it starts. Read it before start_from_blueprint, and tell\nthe person which rule they will most likely want to change.\n",
      "inputSchema": {
        "properties": {
          "blueprint": {
            "description": "The blueprint's slug or name, as list_blueprints answers it.",
            "type": "string"
          }
        },
        "required": [
          "blueprint"
        ],
        "type": "object"
      },
      "name": "get_blueprint",
      "outputSchema": {
        "properties": {
          "answer": {
            "description": "The whole setup, in English, as Markdown.",
            "type": "string"
          }
        },
        "required": [
          "answer"
        ],
        "type": "object"
      }
    },
    {
      "description": "What Typestate is, what it costs, and how to connect to it. Call this\nfirst if you have met this server for the first time and want to know\nwhat it is for. Ask with no `about` and it answers all three parts at\nonce.\n",
      "inputSchema": {
        "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"
      },
      "name": "get_started",
      "outputSchema": {
        "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"
        ],
        "type": "object"
      }
    },
    {
      "description": "The blueprints: whole backends for a named kind of business, each a\nset of English definitions proven on this platform. Ask with the\npurpose in the customer's words, such as \"salon appointments with a\ndeposit\", before you define the first entity of a new backend. A\nblueprint that fits is started with start_from_blueprint, and every\ndefinition in it is the customer's own to change afterwards.\n",
      "inputSchema": {
        "properties": {
          "purpose": {
            "description": "What the backend is for, in the customer's words. Leave it out to list every blueprint.",
            "type": "string"
          }
        },
        "type": "object"
      },
      "name": "list_blueprints",
      "outputSchema": {
        "properties": {
          "answer": {
            "description": "The matching blueprints, one paragraph each, in English.",
            "type": "string"
          },
          "slugs": {
            "items": {
              "type": "string"
            },
            "type": "array"
          }
        },
        "required": [
          "answer",
          "slugs"
        ],
        "type": "object"
      }
    },
    {
      "description": "The integration catalog: the systems a Typestate backend works with,\nmade and checked by Typestate. A built-in one is turned on with one\nsetting tool, which the answer names. A declared one was called\nagainst the real vendor on the date the answer gives, and\napply_integration copies it into a service. Ask before you write a\ndeclaration yourself with define_integration.\n",
      "inputSchema": {
        "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"
      },
      "name": "list_integration_catalog",
      "outputSchema": {
        "properties": {
          "answer": {
            "description": "The matching integrations, one paragraph each.",
            "type": "string"
          },
          "slugs": {
            "items": {
              "type": "string"
            },
            "type": "array"
          }
        },
        "required": [
          "answer",
          "slugs"
        ],
        "type": "object"
      }
    }
  ]
}

Verify it yourself

curl -s https://api.teppi.xyz/v1/evidence/sha256:f41effe21bc2c8852a0fe04abe59792521885975a0dd660fe8a0905c4f1e22ef | sha256sum