# Kismet Developer MCP

> A remote MCP server that teaches your coding agent how to build on the Kismet Developer API, with recipes, docs search, and capability inspection.


The Developer MCP is a build-time surface for coding agents. Connect it in Claude Code, Codex, Lovable, or any MCP client, and your agent can find the right integration recipe, read the shipped API reference, and check what a given credential can do, without you pasting docs into the prompt.

It is deliberately not a runtime API. It never returns guest or booking data and it never accepts a guest token. Generated sites call the SDK or REST API through the documented browser/BFF boundaries; the MCP is how the agent learns to write that code.

> **Status**
>
> Tier 1 (this page) is live: recipes, docs search, capabilities. Runtime read tools scoped to your installation, and OAuth sign-in for them, are tier 2 and not yet available.

## Connect

Endpoint: `https://mcp.kismet.travel/developer-mcp`

Transport is Streamable HTTP over POST. No credential is required to read recipes and docs. If you present a Kismet developer credential, `describe_capabilities` reports your installation's environment and grants.

**Claude Code**

```bash
claude mcp add --transport http kismet-developer https://mcp.kismet.travel/developer-mcp
```

Add `--header "Authorization: Bearer kismet_sk_test_…"` to see your installation's capabilities. Never put a `kismet_sk_` key in a repository or a shared config; use a TEST key for evaluation.

**Codex**

Add a remote HTTP server named `kismet-developer` with the endpoint above in your MCP configuration. Codex reads the same tools, resources, and prompts.

**Lovable and other remote-only clients**

Add a custom MCP connector with the endpoint above. Everything an agent needs is reachable through the protocol itself (tools, resources, prompts), so a client that cannot install a plugin loses nothing.

**Any client, by hand**

```bash
curl -s -X POST https://mcp.kismet.travel/developer-mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

## Skills and plugins

You do not need a plugin. Everything this server offers is reachable through the protocol itself: the tools, the recipe and documentation resources, and the `build:<id>` prompts. Connecting the endpoint above is the whole setup.

A plugin adds one thing on top: **skills**, files your agent loads at the start of a session rather than fetching mid-task, so it already knows the conventions before you ask it anything. Kismet publishes plugins through a public marketplace repository, [kismet-tech/kismet-platform-plugin](https://github.com/kismet-tech/kismet-platform-plugin).

| Plugin | Who it is for | Status |
| --- | --- | --- |
| `kismet-operators` | Property managers running a Kismet business from an AI client: catalogs, guest journeys, demand, Insiders email, ads and audiences | available |
| `kismet-developer` | Builders integrating the Developer API, carrying these recipes as skills | planned |

The developer plugin is not published yet, and this page will not pretend otherwise. When it ships it will be generated from the same recipes this server already serves, so it changes *when* your agent learns them, not *what* it learns. `list_recipes` and `get_recipe` give it the identical content on demand today, which is why the MCP endpoint is the thing to connect now.

Note that `kismet-operators` is a different audience, not an earlier version of the same thing. It operates a Kismet account; it does not help you build against the Developer API.

## Credentials

The server admits three cases and never blurs them:

| Authorization header | Result |
| --- | --- |
| absent | anonymous: recipes, docs, and the shipped operation list |
| valid `kismet_pk_…` or `kismet_sk_…` | your installation's environment (TEST or LIVE), granted capabilities, and the operations they unlock |
| malformed, unknown, revoked, or expired credential | `401`, with a `WWW-Authenticate` challenge pointing at the resource metadata |

A presented credential that fails is refused, not downgraded to anonymous. If you believe you are authenticated, you will not silently receive anonymous answers.

## Tools

Four tools, on purpose. Breadth lives in resources, which your client pages rather than loading into every prompt.

| Tool | What it does |
| --- | --- |
| `list_recipes` | Lists integration recipes with id, domain, status, summary, and the operations each uses. Filter by `domain` or `status`. |
| `get_recipe` | One recipe in full as Markdown: goal, what to use, operations, capabilities, environments, acceptance, and prohibitions. Same text as the `kismet://recipes/<id>` resource. |
| `search_docs` | Token search over the shipped API reference, quickstart, `llms.txt`, and the recipes. Returns resource URIs your client can read in full. |
| `describe_capabilities` | Anonymous: the shipped operations and the capability each needs. With a credential: environment, granted capabilities, unlocked and not-granted operations, allowed origins, and whether writes are sandbox on this installation. |

## Recipes

A recipe is a versioned, repository-owned artifact: what to build, which Developer API operations it uses, what must be true when it is done, and what it must never do. Your agent should start with `list_recipes`, then `get_recipe` for the one that matches the job.

Every recipe carries a **status**, and the status is part of the contract:

- **available**: every operation the recipe needs is shipped and documented. Build against it.
- **preview**: at least one operation it needs is on a review branch and not deployed. The recipe says so in its own text. Use it to shape architecture; do not generate code that assumes it is live.
- **planned**: at least one operation it needs is designed and not built. Architecture only.

Prompts (`build:<recipe-id>`) exist only for available recipes. A prompt is an invitation to build, and the server does not invite building against unshipped contracts.

Available today: rendering a rental listing and detail page from published resources, showing an availability calendar without inventing prices, and creating a sandbox booking request on a TEST installation.

## Resources

- `kismet://recipes/<id>`: one recipe, Markdown
- `kismet://docs/reference/<operationId>`: one operation reference page, the same Markdown twin linked from each page in this site
- `kismet://docs/quickstart`: the quickstart
- `kismet://docs/llms.txt`: the machine-readable index of everything shipped

The docs the server serves are the docs you are reading. Both are generated from the same source in the API repository, so `search_docs` cannot describe an operation this site does not.

## Boundaries

- Never a guest token. The Developer MCP is a build-time surface for the builder's agent, not a runtime surface for the guest.
- Never runtime data. Guest, booking, and saves reads are the SDK and REST API, behind the browser/BFF boundary, and are tier 2 for the MCP.
- TEST and LIVE are separate installations with separate credentials, and crossing them is refused. `describe_capabilities` on a TEST key tells you writes create sandbox rows; on a LIVE key it tells you sandbox-only operations are refused.
- Server keys (`kismet_sk_…`) never belong in a browser, a repository, a build artifact, or a shared MCP config. Publishable keys (`kismet_pk_…`) are origin-bound and browser-safe.

## Discovery documents

- `https://mcp.kismet.travel/.well-known/oauth-protected-resource/developer-mcp` names the resource and links back here. It lists no authorization server in tier 1, because a developer credential is issued by the Kismet control plane, not by an OAuth login.
- `https://kismet.travel/.well-known/mcp.json` lists every Kismet MCP server, including this one, under `servers.developer`.