Jev MCP Server: How to Use Jev Inside Claude Code, Cursor and Codex

If you've searched for a Jev MCP server, here's the thing worth knowing before you spend an evening on it: TypeSafe doesn't publish one. There's an HTTP API, a Python SDK and a JavaScript SDK, and that's the official surface.

What does exist is an MCP server that can call Jev, along with everything else you've connected. That's Swytchcode's MCP server, and the distinction matters because it changes what you get. A hypothetical Jev-only MCP server would let your coding agent ask Jev questions. A server that exposes Jev and Gmail and Stripe lets your agent ask Jev a question and then act on the answer, which is the part you actually wanted.

This post is the setup, the two profiles, and the pattern that makes it useful rather than just connected.

What you get over MCP

Swytchcode's MCP server exposes its CLI as tools. The default agent profile gives seven:

The full profile adds eight more: init, bootstrap, version, get, doctor, policy_check, policy_add and policy_remove.

The docs recommend agent for deployed agents, and the reason is worth stating plainly: in the full profile an agent can call policy_remove. An agent that can delete the policy that constrains it is not constrained. Use full while you're setting a project up at your own keyboard, and agent for anything running on its own.

Setup

Install and sign in first:

npm install -g swytchcode
swy login
swy init --mode=sandbox

swytchcode init asks which editor you use and whether to run in production or sandbox mode. Start in sandbox.

Then connect Jev and whatever it's going to decide about:

swy get jev
swy get gmail

swy add method <jev-method-id>              # find it with: swy list methods jev
swy add method gmail.user.messages.get
swy add method gmail.user.modify.create

swy auth connect jev      # paste your Jev API key
swy auth connect gmail    # opens Google's sign-in

Credentials go into Swytchcode's own store at ~/.swytchcode/credentials.db, not into your editor's config, not into a .env file, and not anywhere the model can read them back. Your coding agent can call Jev without ever seeing the key. The authentication docs cover the storage.

Claude Code

One command registers it:

swy mcp serve --claude

To switch profiles later, remove and re-register:

claude mcp remove swytchcode
swy mcp serve --claude --profile full

Cursor

swy init --editor=cursor

That adds a stdio entry to ~/.cursor/mcp.json and writes a rule file at .cursor/rules/swytchcode.mdc so Cursor knows when to reach for the tools.

Codex, Windsurf, Copilot, Gemini CLI, and the rest

Same shape, different flag:

Any other MCP client

The generic config points at the stdio server:

{
  "mcpServers": {
    "swytchcode": {
      "command": "swy",
      "args": ["mcp", "serve"]
    }
  }
}

Transports: stdio locally, HTTP for remote agents

stdio is the default and the right choice for a desktop editor. The editor spawns the process, talks over pipes, and there's no port and no token to manage.

swy mcp serve

HTTP is for agents that aren't on your machine, or that can't spawn processes:

swy mcp serve --transport http --port 5476
swy mcp serve --transport http --port 5476 -d    # background
swy mcp status                                   # check the daemon

It serves at http://127.0.0.1:5476/sse, bound to localhost only. HTTP needs a bearer token, which stdio doesn't:

swy mcp token            # print it
swy mcp token --rotate   # rotate it

The token lives at ~/.swytchcode/mcp_token. Rotate it if it ever ends up somewhere it shouldn't, which in practice means if it ever ends up in a chat transcript or a screenshot.

The pattern that makes this worth doing

The failure mode of giving a coding agent API access is that it writes plausible, wrong calls. It invents an endpoint, guesses a parameter name, and you find out at runtime. We've written about why that happens and it isn't the model being careless; it's being asked to recall an API surface it can't see.

MCP changes that, if you use the tools in the right order:

discover "label an urgent email in gmail"     -> candidate canonical IDs
info gmail.user.modify.create                 -> exact inputs and outputs
exec gmail.user.modify.create { … }           -> the call, with credentials attached

A coding agent using list and info to find the right method and check its contract before running anything.

The agent isn't recalling the API any more. It's reading it. That's the whole difference, and it's why the info step is the one not to skip even though agents will try.

What this looks like in practice

Once it's registered, you ask in plain language and the agent does the three steps itself. In Claude Code:

Read my last 20 inbox messages, ask Jev whether each one needs a reply today, and label the urgent ones.

What happens underneath: the agent calls discover to find the Gmail listing method, info to check the parameters, exec to fetch the messages, exec against the Jev method with a noul question per email, then exec on gmail.user.modify.create for the ones over your threshold.

You didn't write that code. You also didn't hand the agent your Gmail token, and it couldn't have sent an email even if it tried, because gmail.user.send.create1 was never added to tooling.json.

That triage flow written out properly as a script is our Gmail triage walkthrough, and it's worth reading alongside this: MCP is the fastest way to explore a workflow, and a script is how you ship it on a schedule.

Keeping an agent on a short leash

Three controls, in order of how much they matter.

The method allowlist. Only what you swy add method can run. This is a stronger guarantee than any instruction in a system prompt, because it's enforced below the model.

The agent profile. Seven tools, with policy read-only. The agent can see the rules it's operating under and cannot change them.

Policies. Amount ceilings, approval holds, denials. Checked before every execution, whatever the agent intended. The policies overview covers the engine and policy rules has the schema. For anything that moves money, see our refund approver build, where the policy does the work the model shouldn't be trusted with.

Sandbox mode sits under all of it while you're still experimenting, and it lives in .swytchcode/tooling.json rather than an environment variable, so it doesn't get lost between shells.

When MCP is the wrong tool

Worth saying, since the answer isn't always yes.

Scheduled or unattended work. MCP needs a client driving it. A nightly triage job is a script calling exec from @swytchcode/runtime, not an editor session.

High-volume loops. Routing a thousand tickets is a script. The round trip through an agent is pure overhead when the decision logic is already settled.

Anything you need to be identical every run. An agent choosing methods at runtime is a feature while you're exploring and a liability in production. Once the shape is known, pin it in code.

MCP earns its place in the exploring phase: finding the right methods, checking shapes, trying a Jev question set against ten real records before you commit to it. That's genuinely faster than reading docs. Then you write the script.

FAQ

Is there an official Jev MCP server from TypeSafe?

Not as far as we can tell. TypeSafe ships an HTTP API and SDKs. Jev over MCP comes via Swytchcode's server, which exposes it as a tool alongside your other integrations.

How do I add Jev to Claude Code?

Install the CLI, swy get jev, swy auth connect jev, then swy mcp serve --claude.

How do I add it to Cursor?

swy init --editor=cursor, which writes the stdio entry to ~/.cursor/mcp.json.

What's the difference between the agent and full profiles?

agent has 7 tools and read-only policy access. full has 15, including policy_add and policy_remove. Use agent for anything running unattended.

Does the agent see my API keys?

No. Credentials live in Swytchcode's store and get attached when a call runs. The agent calls a method; it never handles the key.

stdio or HTTP?

stdio for desktop editors, HTTP for remote agents or clients that can't spawn processes. HTTP requires a bearer token from swy mcp token.

Can the agent change its own policies?

In the full profile, yes. That's why the agent profile exists.

Where does the MCP bearer token live?

~/.swytchcode/mcp_token. Rotate with swy mcp token --rotate.

Can I run this for a team?

The MCP server is local and binds to localhost. For shared or multi-tenant use, the runtime's tenant options are the better fit; see the JavaScript runtime.

Wrapping up

The thing people search for doesn't exist, and what does exist is more useful: an MCP server where Jev sits next to the APIs its decisions are about. Your agent asks Jev whether an email needs a reply, then labels it, through one runtime with one credential store and one audit log.

Setup is three commands. The habit that makes it work is discover, then info, then exec, reading the API instead of recalling it.

Start with the MCP quickstart, the Jev integration, or hand your coding agent our skills file and let it set the project up itself.