Kismet Developer MCP

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

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

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.

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.