Use WorkerKit with Instinct.

Before you start

What you need.

A WorkerKit account. The Free plan is enough and no card is needed. Admin access is what creates a manager key, and that is only needed for the operating surface in step 3.

A client that actually connects, for step 3: any MCP client, the wk CLI, or any host that can call an HTTPS API. Instinct is not one of them today, and saying so is the point of this page.

For step 2 only, an Instinct assistant whose email address has been claimed at mail.instinct.com. Instinct is invite only as of 2026-09-15, so that step needs an existing member. Nothing else here does.

Why this route: because no other one exists. Two independent passes on 2026-09-15 looked for a remote MCP server, a local one, an OAuth path, a header path, a REST API, a connector directory and an actions surface, and found none published. The vendor's sitemap lists one URL, no documentation or developer site is published, and the MCP project's client list does not name Instinct. A procedure here would be fiction.

That is not the same as "Instinct has no integrations". It has several, and they all run outbound: the person authorises the assistant to act inside their own accounts, which the Terms call Connected Services and the Privacy Policy names as Google Workspace over Google OAuth. What is missing is the reverse direction, the one a third party needs.

One warning worth reading twice: do not solve this by handing Instinct a WorkerKit sign-in or a manager key to drive the dashboard with. A credential in a chat is a credential in a log. Scripting the other way, into Instinct, is barred by its own Terms, which prohibit automated access to the Services. Deliver to the mailbox instead and keep the key in an MCP client, the wk CLI or the REST API.

The case for connecting at all is on the Instinct page.

Step 0. Human, two minutes

Know what connects and what does not.

Read this before anything else, because it saves an hour of looking for a settings screen that is not published.

1. 01

   There is no Instinct MCP server and no Instinct connector

   Checked twice on 2026-09-15 against live vendor sources: no remote MCP mount, no local one, no OAuth or header path, no public REST API, no connector directory, no extension store and no actions surface is published. The word MCP appears on none of the pages the vendor publishes.

2. 02

   Its integrations run outbound, not inbound

   The Terms let the assistant act inside the accounts you authorise, which the vendor calls Connected Services; the Privacy Policy names Google Workspace over Google OAuth. Announced partnerships run the same way. Nothing in that model lets an outside service register a tool server with Instinct.

3. 03

   Automated access is out of bounds, and access itself is invite only

   Its Terms of Use prohibit using any "robot, spider, crawlers, scraper, or other automatic device" against the Services, which rules out a scripted bridge and is why this page offers a delivery rather than an automation. instinct.com also states that Instinct "is currently available to a private access group as we're scaling up compute", by waitlist or an invitation from an existing member. Only step 2 needs an Instinct account at all.

This position is dated on purpose. The vendor announced four integrations in roughly three weeks before this page was written, and not one of them let an outside service register anything, so the claim above is true as of 2026-09-15 and worth re-checking at instinct.com. The WorkerKit half is stable: the fleet is reachable from MCP, from a terminal and over plain HTTPS whatever Instinct does next, which is step 4.

Step 1. Human and agent, about five minutes

Give the fleet a worker, and mail its report to the assistant.

A report needs a worker to write it, so this step does both: install one, then point its email delivery at the assistant's own address. Email is a first-class WorkerKit channel, which is why this bridge needs nothing from Instinct.

A new WorkerKit account starts with no workers, so the last step of setup is getting one. A kit is a ready-made worker: its instruction, its exact app permissions and its schedule, written and reviewed in advance, so installing one is how a fleet usually starts rather than a shortcut. There are two paths, and either ends with something to operate.

1. 01

   The one-click path: install a kit from its page

   Browse the catalog at workerkit.ai/kits, open a kit whose job you recognise, and install it. It arrives pre-instructed, pre-permissioned and pre-scheduled, and asks for whatever it needs to connect. This path needs no scope on the manager key at all, so it works on the first session whatever the key can do.

2. 02

   The agent path: shortlist, preview, approve, install

   With installKits on the key, the assistant can do the whole thing in chat: shortlist with kits_search, read the candidate with kit_get, then call kit_install_preview to surface its setup questions and exactly what the new worker would be allowed to touch. Put that in front of the person in plain words, and call kit_install once they approve, with deploy set to true so the new worker is actually able to run (that half needs manageDeployments on the key; without it the worker is installed but inert until worker_deploy). The new worker's key is shown once in the response.

3. 03

   Then run it once and read the receipt

   A worker earns its place on the first run. Trigger it with worker_run, follow run_events until a terminal event arrives, and report the digest and the settled cost from run_get. Set a schedule with schedule_create when the person is happy with what it did, and the fleet is not just connected, it is working.

• 1. Claim the assistant's address (an existing Instinct member, in a browser) https://mail.instinct.com
• 2. Read the channel types this account can use, then add the email one with that address delivery_channels delivery_create
• 3. Run the worker once and confirm the report went out worker_run run_get delivery_list

This is a delivery statement rather than an integration: WorkerKit sends mail to an address and Instinct reads mail, so neither side registers anything with the other. Our half ends at the send. What the assistant does next is ordinary mail handling, the vendor documents no rule you can set from outside, and nothing returns here.

Treat the mailbox as one way: a run that ends awaiting input asks on its delivery channels, but the answer comes back with run_answer, through a surface you operate. Deliveries are per worker, so the workers whose output belongs in front of the assistant get that address and the rest keep sending where they sent before.

Step 2. Human and agent, about a minute

Operate the fleet from a surface that does connect.

Instinct stays the assistant you talk to. The fleet is run from any MCP client, from the wk CLI, or over the REST API, and the manager key never leaves that surface.

The fleet mount is an OAuth 2.1 authorization server as well as an MCP server, so a client that supports OAuth connects with nothing pasted anywhere: it discovers the server, registers itself, and sends the person to a consent page to approve.

If the fleet is empty, stop after step 3 and say so: a new account has no workers yet, and the steps above have already proved the setup, because the key authenticated and both read scopes answered. Do not read it as a fault, and do not invent a worker to run. Go to the first-worker step and give the fleet something to do.

If the fleet has workers, pick one whose effects are reads. Judge it from the instruction and the permissions, never from the name: a worker whose apps are all read-level and whose instruction only gathers, summarises or reports is safe to run; one that sends, posts, writes, orders or pays is not, whatever it is called. If none is clearly read-only, run one with an explicit prompt for that run bounding it to a read.

1. 01

   Give the client the URL and nothing else

   The fleet mount publishes OAuth discovery, so a client that supports it finds the authorization server on its own and registers itself. There is no client ID to create, no secret to store and no redirect address to register in advance.

2. 02

   Approve on the WorkerKit consent page

   The client sends the person to https://workerkit.ai/mcpauth. Signing in there is what proves who is connecting; nothing is typed into the assistant.

3. 03

   An account admin picks the key the client will hold

   The consent page lists the account's manager keys and can create one on the spot, so a first connect needs no visit to Fleet access beforehand. It is admin-only on the server, not just in the page: a member sees an honest notice rather than a broken screen.

4. 04

   Scopes are chosen with the key, and are the whole of the reach

   Whatever that key carries is exactly what the assistant can do, and nothing on it reaches a connected app. Narrow it now or widen it later; a new key drops into the same connection.

• Any MCP client: the public catalog, no credential at all https://mcp.workerkit.ai/directory
• Any MCP client: your fleet, by URL, approved on the consent page https://mcp.workerkit.ai/workers Then approve at https://workerkit.ai/mcpauth
• A client that takes a static header instead Authorization: Bearer pe_mgr_...
• 1. The directory is alive: confirm a kit count comes back directory_overview
• 2. The fleet list: report how many workers the assistant can see workers_list
• 3. Recent runs across the fleet: confirms readRuns runs_feed { "limit": 5 }
• 4. Before running anything, read what that worker does and what it may touch. Both ride on readWorkers, and this is the step that decides whether the run is safe instruction_get worker_permissions_get
• 5. Run it with the person's approval, then poll every 3 to 5 seconds until a terminal event arrives: run.succeeded, run.failed, run.blocked or run.awaiting_input worker_run run_events { "afterSeq": <lastSeq> }
• 6. Read the receipt: costAuthority first, then modelCostUsd run_get

The catalog mount takes no credential at all, on either path. It is the fastest proof that the client can reach WorkerKit, and it is worth adding first for exactly that reason: if it connects and the fleet mount does not, the problem is the credential rather than the wiring.

Nothing is pasted into the chat on this path, which is its real advantage: the credential never passes through a message, a log or a screenshot, and revoking it later is one action in the dashboard rather than an edit inside the assistant.

A client that cannot run an OAuth flow takes the same fleet on one header instead. An account admin creates a key at https://workerkit.ai/fleet-access, copies it once, and it becomes the value of an Authorization header on the fleet mount. That header is the whole of the authentication: there is nothing to register and nothing to pre-approve.

A key carries the scopes it was granted when it was created. Granting a scope later never reaches an existing key: if a call answers 403 OPERATION_NOT_ALLOWED, an admin re-scopes the key at Fleet access or creates a new one, and the new key drops into the same place. Read key_info rather than assuming.

Read costAuthority first, then modelCostUsd beside it, and report both. A null finalDigest is not a failure: a run produces one only when its harness wrote a report. A costAuthority of unbilled_estimate, none or in_flight is not a failure either; it says how far to trust the number, and the operating rules below say what each value means.

A Skipped run is also a pass, and it is the cost brake working: the gate refused the run before any money moved. Report the skipReason rather than retrying. Then report the fleet size, the active scopes, and what the test cost, and the fleet is live.

Step 3. Nobody today, and about a minute when it happens

What would change the day Instinct publishes a door.

Nothing on the WorkerKit side. Both doors are already open and have been since before this page existed, so the work is a paste and an approval.

1. 01

   If it adds remote MCP with a sign-in flow

   Give it the fleet mount URL and nothing else. The mount publishes OAuth discovery and accepts anonymous dynamic client registration, so there is no client ID to create and no key to paste: the person approves on the WorkerKit consent page and an account admin picks the manager key that connection holds.

2. 02

   If it adds a header field, or an HTTPS surface but not MCP

   An admin creates a manager key at https://workerkit.ai/fleet-access and it becomes the value of an Authorization header on the fleet mount, which is the whole of the authentication. A client that cannot speak MCP at all reaches the same fleet over the REST API at https://workerkit.ai/api, behind the same key and the same scopes. The door differs; the reach does not.

3. 03

   If it publishes nothing

   Step 2 still works, because it never depended on a door. Mail is the bridge, and it needs no cooperation from either vendor. Until a door exists this page claims no compatibility it cannot demonstrate, which is the whole of its value: an instruction for a menu that does not exist costs a reader more than an honest no.

Classification on demand

Create a decision worker from your questions.

Use this from another connected client, the CLI or the API. This does not add a direct connection to this assistant.

Reuse an existing worker or decision kit when its questions fit. For a custom classification task, creation compiles a supported source recipe and typed questions into a private kit and an installed decision worker. Optional deploy:true adds deployment; creation never starts a run or adds a schedule. The kit can be edited and published later through the normal kit lifecycle.

On the workers connection, call kit_app_tools(purpose:"decision") for recipes, argument schemas, permissions and examples, then kit_authoring_guide(section:"decision"). Check account connections with apps_list; public discovery does not check them. Send the request to decision_worker_create, follow nextCall, then use worker_run and run_get. Running needs runWorkers; results need readRuns. Use instruction_get / instruction_set for saved category or level answers, or answers on one run. Structural question/source changes need a revised kit and a replacement install. Check receipt status, coverage, omissions, warnings and cost before claiming completion.

Start with email-previews, calendar-events or sheets-rows. These recipes return judgments without app writes. Email previews do not include full threads; calendar events are invitation data, not transcripts; Sheets needs a Google file ID, a finite tab-qualified range and a columns map. A connected app alone does not make every tool a supported source. Source filters select evidence, not permissions: the Sheets recipe grants spreadsheet reads across the linked Drive account.

Supply 1–8 questions: choice with named options, score with ordered levels, or noul for the probability of a statement. Choice adds unclear automatically. Set an explicit confidenceFloor between 0 and 1; it routes uncertainty and does not promise accuracy. maxItems is 1–50, default 20. Creation requires publishKits and installKits; optional deployment also needs manageDeployments.

Use a fresh requestId for each new worker. Retry with the same ID and identical body to recover the original receipt; a changed body returns 409. The response includes tokenId for MCP/CLI worker commands, stable workerId, kitSlug, readiness and nextCall. A deploymentError means the worker already exists: fix deployment on that worker. The receipt is a snapshot; check current worker readiness before running. No worker API secret is returned.

The workers connection includes discovery and authoring, so classification needs one MCP connection. Its full profile has 91 tools (84 manager tools and 7 public discovery reads); only decision_worker_create is new. For a smaller list, a client that supports custom headers can send X-WorkerKit-Profile: decision on every request, including initialization, listing and calls, to select 20 workflow tools. A server operator can instead set MCP_WORKERS_PROFILE=decision. The endpoint and existing sign-in stay the same; a profile grants no additional permissions. Reconnect and relist after changing profiles. Use the advertised tool list: fleet administration, publishing and event-stream tools require the full profile. Successful responses include structured content and a text fallback; creation declares an output schema.

Read the request example and full contract.

Least privilege

What each scope grants.

The key's scopes are exactly its reach, and a refusal names the scope it wanted. Start with the reads and add scopes as the work asks for them.

Operating rules

What the agent follows on every call.

The same rules the skill file carries, so a session that read neither still has them. Every row is a fact of the platform, not advice.

Quick answers

Symptoms, causes, fixes.

Each WorkerKit failure names itself in the response, so an agent never has to guess which one it met: read the code, apply the row, and carry on.