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

The public gateway, nine-tool server, and Kismet Developer plugin are generally available. Runtime read tools scoped to your installation, and OAuth sign-in for them, remain a separate tier 2 and are not 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 and Claude Code

For the complete Claude experience, install the plugin. In Claude, open Customize → Plugins → Personal plugins → + → Add marketplace, add https://github.com/kismet-tech/kismet-platform-plugin, then install Kismet Developer.

In Claude Code, run:

/plugin marketplace add kismet-tech/kismet-platform-plugin
/plugin install kismet-developer@kismet-platform

If you only want the remote MCP without the bundled skills, run:

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

Install the full plugin:

codex plugin marketplace add kismet-tech/kismet-platform-plugin
codex plugin add kismet-developer@kismet-platform

Open a new task after installation so Codex loads the skills and MCP server.

Lovable

Open Connectors → Chat connectors, add a custom MCP server named Kismet Developer, and paste the endpoint above. The connection is available to Lovable while it builds your application; it does not add Kismet runtime behavior to the deployed application.

Lovable receives the canonical tools, resources, prompts, and recipes through the MCP. It does not install the six local workflow skills bundled with the Claude and Codex plugin, so begin with: “Call list_recipes, choose the smallest available recipe for this task, then call plan_integration before editing the application.”

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 can use the MCP without a plugin. Its tools, recipe and documentation resources, and build:<id> prompts are all available through the protocol.

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, SDK, and Fixtures	available

The developer plugin contains six workflow skills for SDK sites, semantic search, branded guest accounts, TEST booking, fixture-backed builds, and pre-deployment validation. The MCP recipe and operation registry remains canonical, so the skills fetch current contract details instead of carrying a second API description.

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

Nine focused tools. 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.
get_operation	Returns the canonical generated reference for one shipped operation, including capability, request, response, errors, and examples.
plan_integration	Builds a bounded plan for one available recipe, framework, and explicit fixtures or live data mode.
get_fixture_plan	Returns one Fixture’s registry status, dependencies, install methods, data coverage, settings, and missing commerce actions.
validate_integration	Checks supplied source and configuration text for deterministic contract violations. It accepts content, never a filesystem path.
explain_problem	Explains a stable Kismet problem code and the safe response.

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 recipes cover rental list/detail, synchronized availability, natural-language BookableProduct search, TEST booking requests, branded guest authentication, guest self, memberships, email state, saved-payment readiness, saves, signed-in TEST booking, and session recovery. Benefit projections remain planned and are labeled as such.

The semantic-search recipe uses searchBookableProducts for live and TEST API data. A fixture-backed alternate implementation depends on the lane #54 semantic-search Fixture reporting supported coverage. Until then, agents must fail loudly rather than present fixture output as live search.

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.
• Custom data-object API and MCP tools wait for the #77 reference implementation and #46 contract review. Agents must not invent generic object CRUD.

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.