Which Copilot is this, and where do I set it up?

Microsoft Copilot Studio, at copilotstudio.microsoft.com, inside the agent you want to give the fleet to: Tools, then Add a tool, then New tool, then Model Context Protocol. Microsoft 365 Copilot itself has no field anywhere for an end user to paste an MCP server URL, and neither does the consumer Copilot app. The route into Copilot is the agent: build it in Copilot Studio, publish it to the Teams and Microsoft 365 Copilot channel with Make agent available in Microsoft 365 Copilot selected, then type @ in Copilot and pick it.

Do I have to paste a key anywhere?

Yes. Connect https://mcp.workerkit.ai/workers with API key authentication and a manager key from workerkit.ai/fleet-access. Set the Authorization header value to Bearer followed by your key. The setup guide also covers OAuth.

Which header name do I use, and will Authorization work?

Use Authorization with the value Bearer followed by your key. Microsoft documents a custom header name but does not explicitly list Authorization as accepted. If your tenant rejects it, use the OAuth alternative in the setup guide, which requires an allowed redirect URI.

Can Copilot read my email or CRM through WorkerKit?

Only through workers you set up. The key inside that connection is a manager key with no app credentials, but run results (with readRuns) and an Action worker's tool results (with invokeActions) can include data from the apps that worker was granted. Choose the worker's app access and the key's scopes together. Copilot also keeps exactly the Microsoft Graph access the person signed in already had, which this connection neither widens nor reads.

What does the agent need to set this up?

A Copilot Studio agent with generative orchestration on, because Microsoft states that generative orchestration is required to use MCP at all. A WorkerKit account with admin access, and a manager key created at workerkit.ai/fleet-access. The WorkerKit skill file at workerkit.ai/microsoft-copilot/SKILL.md, whose contents go into the agent's Instructions field. Reaching Copilot Studio itself needs a Copilot Studio license, a Microsoft 365 Copilot license, or membership of the authors security group, and a trial license can build and test but cannot publish.

What can an admin block, and what does the tenant have to allow?

Three gates, and none of them is WorkerKit's. MCP access in Copilot Studio rides Power Platform connectors, so a tenant data policy over connectors also governs this server and its tools, and an admin can block it outright. Publishing the agent to everyone in the organization is a submission for admin approval rather than a maker decision; sharing it with named people by link is not. And the tenant has to allow Power Platform apps in Teams before the agent can be installed there at all. If any of the three is closed, nothing is broken on the WorkerKit side: the mount is public and the manager key is the only credential involved.

How does the agent get a worker's results?

Two paths, and neither keeps a Copilot session open. The agent reads runs itself: runs_feed across the fleet, run_get for one run, and each receipt carries the closing report, the typed digest when the run produced one, and the settled cost. The worker also delivers on its own, to whichever channels are set on it: email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook. Teams is one of them, so a report can land in the same place the agent answers from.

I connected it and the fleet is empty. What now?

Nothing is broken. An account has no workers until someone installs a kit or clones one, and the reads answering at all is the proof that the wiring and the key are good. A kit is a ready-made worker: its instruction, its exact app permissions and its schedule, written in advance. Open one at workerkit.ai/kits and install it from the page, which asks no scope of the key. With installKits on the key the agent can do it without leaving Copilot: kits_search to shortlist, kit_install_preview to show exactly what the new worker would be allowed to touch, kit_install when you approve.

The WorkerKit side starts free and asks for no card: 5 workers, 500 tool calls a day, and the whole safety layer. A run pays for its model tokens at the provider list price with no markup, against a prepaid wallet or a provider key of your own, and stops at the per-worker and fleet ceilings you set. Giving an agent the fleet costs nothing here. Copilot Studio is licensed and metered separately on Microsoft's side, which WorkerKit neither sets nor sees.

For Microsoft Copilot

AI workers for Microsoft Copilot.

Microsoft Copilot is three products under one name, and one of them, Copilot Studio, adds a remote MCP server by URL. WorkerKit arrives there as a tool: a fleet of background AI workers with their own instruction, memory, schedule, budget and pre-scoped app access, hosted around the clock and reporting back in short, costed digests. The agent you build in Copilot Studio operates them, and publishing it to the Teams and Microsoft 365 Copilot channel is what puts the fleet in front of the people who already work there.

Start here

Add WorkerKit to Copilot through Copilot Studio.

Microsoft 365 Copilot reaches MCP servers through an agent you build in Copilot Studio. Create a key, add WorkerKit as an MCP tool, then publish the agent.

01
Create a manager key
At AI access, name it Copilot Studio, start with the read scopes and copy it once.
02
Add WorkerKit
Under Tools, choose Add a tool, New tool, Model Context Protocol. Name it WorkerKit and enter the address below. Choose API key, type Header, header name Authorization. Enter Bearer, a space, then your key.
03
Publish to Microsoft 365 Copilot
In Channels, choose Teams and Microsoft 365 Copilot, keep Make agent available in Microsoft 365 Copilot selected and publish. Then type @ in Copilot and pick the agent.

WorkerKit address, API key on the Authorization header https://mcp.workerkit.ai/workers

Create a manager key At AI access, admin only. It is shown once, so keep it to hand.
Open Copilot Studio Where the agent and its tools live. It needs generative orchestration, the default for new agents.

The setup guide has every screen, the instructions to give the agent, and what to do if your tenant refuses the header.

Why WorkerKit

Control your AI workforce from Microsoft Copilot.

Ready-made, self-learning AI workers with only the access each job needs, a budget you set, and a record of every job and action.

Put AI workers on jobs with real ROI. Install a kit for work your team already repeats, and a worker arrives with its instructions, app permissions and schedule already written and reviewed. Start with the job that costs the most time, or build your own kit.
Turn your AI workers’ jobs and data into shared company knowledge. Each job’s instructions, apps and limits live in one kit your team keeps current, and workers that use the Records app keep what they find in shared tables and lists your team can open. Your team and every connected assistant work from the same process.
Choose what each AI worker can access. Each worker holds its own grant for each app, read-only by default, and nothing it reads can widen it. An assistant's key carries only the scopes you choose and never an app credential.
Track what your AI workers did and what they changed. Every run leaves a receipt with its result and its cost, and every tool call is logged with its outcome, so you can see what each worker did, when, and at what price.
Keep AI spending within the limits you set. Each worker has a per-run and a daily spending limit, under a limit for the whole account. When one is reached, new runs stop before any money moves, and the receipt says why.
Your AI workers learn as they work and keep getting better. A language worker can check every run against its job's quality criteria. A change that makes it better waits for your approval or, in Apply proven changes mode, applies on its own once it passes a comparison on your own examples. Its runs also propose what it should remember, and you approve what it keeps.

What Microsoft Copilot is

Three products, one name.

Microsoft 365 Copilot is the work assistant: Copilot Chat at m365.cloud.microsoft, the same assistant in Teams and inside the Office apps, grounded on what Microsoft Graph already lets you see. Microsoft Copilot Studio at copilotstudio.microsoft.com is a separate low-code product where makers build agents and attach tools to them, and it is the one surface that takes a remote MCP server by URL. The consumer Microsoft Copilot app is a third thing again, with a short fixed list of personal-account connectors and no custom connector mechanism at all.

Knowing which of the three you are in is most of the work, because the connection is built in one of them and used in another. You add WorkerKit in Copilot Studio. You reach it from Microsoft 365 Copilot, by publishing the agent that holds it.

Surface	What it is	Can it hold a WorkerKit connection
Microsoft Copilot Studio	The low-code product where agents are authored and tools attached, at copilotstudio.microsoft.com.	Yes, and this is the door. Tools, then Add a tool, then New tool, then Model Context Protocol takes a server URL and an authentication choice.
Microsoft 365 Copilot	The work assistant in Copilot Chat, Teams and the Office apps, grounded on the tenant's Microsoft Graph data.	Not directly. No field in it takes an MCP server URL. It reaches the fleet through an agent published to the Teams and Microsoft 365 Copilot channel.
Declarative agents, from the Microsoft 365 Agents Toolkit	The developer route to a Microsoft 365 Copilot agent, built in Visual Studio Code.	Yes, on the other door. Microsoft supports Entra SSO, OAuth 2.0 authorization code, dynamic client registration and no authentication for MCP plugins here, and states that API key authentication is not supported for them.
The consumer Microsoft Copilot app	The personal-account assistant, with a fixed vendor-curated connector list.	No. Microsoft documents no custom connector and no MCP mechanism on this surface, so there is nothing to wire and this page does not pretend otherwise.

Copilot is strong at the work you watch it do, inside documents and mail you already have access to. A fleet beside it takes the standing jobs: the ones that keep running when no chat window is open, hold their own access to systems outside the tenant, and report a paragraph rather than a screen.

Hired specialists

What a worker adds beside Copilot.

An AI worker is a background agent with its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs, so neither Copilot Studio nor a Copilot chat window has to stay open for them.

Aspect	Microsoft Copilot	A WorkerKit worker
Context	One conversation, grounded on the Microsoft 365 content your account can already reach	Its own, sealed per run; only the digest returns
Model	The model the surface provides	Chosen per worker from any supported provider, or your own provider key
Reach beyond the tenant	Whatever connectors and tools a maker attached to the agent	Its own connected accounts, wired once per worker, under a per-app grant and a firewall
When it runs	While someone is asking	Hosted around the clock: on demand, on a schedule in its own time zone, or on a signed inbound webhook
What comes back	The answer, in the chat	A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost
Memory	The instructions and knowledge sources the agent was configured with	The worker's own rules and facts, carried across runs, and approved by you before a run may use them
Taking it back	Remove the tool from the agent, or let an admin block the connector tenant-wide	Disable or revoke one worker; nothing else moves

The operator pattern

Copilot operates. Workers work.

Step	Who	What happens
1	You	Ask in plain language, in the Copilot Studio test panel, in Teams, or in Microsoft 365 Copilot by typing @ and picking the agent. "Which workers ran today?", "Run the invoice chase now", "Pause the scanner."
2	The agent	Generative orchestration matches the request to a WorkerKit tool and calls it over the MCP connection, carrying the manager key that connection holds. It reads its key's scopes first with key_info.
3	The worker	Executes in its own context, on its own runtime, on its schedule or on demand. None of it depends on the Copilot session staying open.
4	Both	The agent reads the result with runs_feed and run_get: one connection covers the whole fleet, and the run's receipt carries the digest, the typed structure when the run produced one, and the settled cost. People receive it through the worker's delivery channels, Teams among them.

The Copilot Studio agent becomes the fleet operator, and generative orchestration is what makes that work: the agent reads the tool descriptions WorkerKit publishes and picks the matching one from what the person asked. Published to the Teams and Microsoft 365 Copilot channel, the same agent answers from the assistant people already have open.

Why Microsoft Copilot and WorkerKit

Each one covers what the other is not for.

Use Copilot for work grounded in your tenant, where the answer belongs in the document or the thread you are already in. Use a WorkerKit worker for run unattended against my apps, on a schedule, with its own grant, and deliver to Teams.

Microsoft Copilot strength	What WorkerKit adds beside it
Grounded in the tenant, under the permissions each person already has	Workers that hold their own accounts outside the tenant, each with an explicit per-app grant rather than the operator's own reach
Copilot Studio: a low-code builder with a large connector catalogue behind it	A hosted MCP surface that arrives as one tool with a documented vocabulary, so the agent gains a whole fleet from a single connection
Agents that land where people already work, in Teams and the Office apps	Runs that outlive the chat, and delivery to email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook
Tenant governance: data policies over connectors, and admin approval before an agent reaches the organization	A second, narrower layer under it: per-worker grants, an app firewall on every tool call, and a revocable manager key that holds no app credentials
Generative orchestration, which picks a tool from its description	Tool names, cost fields and safety rules written down in a skill file, so the agent plans against facts rather than guesses

What it unlocks

Background work that stays out of the chat.

Each run executes sealed inside its own context, settles its exact cost and returns a digest. The worker remembers its own state. Your conversation stays clean.

Sealed jobs, small returns Every job runs in its own context and only the digest comes back. A long crawl becomes the few paragraphs that matter, so many workers fit in one conversation.
The right model per job Inexpensive models scan, frontier models judge. Every run is priced to the token, with reserved-versus-settled tracking, so background work is never a black box on your bill.
Money you can trust A run that never started costs nothing. A run that went silent mid-flight is absorbed by WorkerKit and labelled as an unbilled estimate. A failed run settles at actual usage with no minimum charge.
Standing monitors and briefings Workers watch on a schedule and report only what is new, so you stop relying on remembering to ask.
Two-way work A run that needs input does not guess or stall. It asks on every delivery channel and resumes as a linked follow-on run when you answer.
Memory that compounds Rules and facts persist across runs, so the tenth run is smarter than the first. Anything a run proposes for memory waits for your approval before a future run may use it.
Kits: install one or make your own Browse the catalog, install a ready-made worker, or author your own through the authoring guide, the validator and the publisher. Every path runs the same validators.
Fleet operations Clone a tuned worker for the next client, set budgets, route deliveries, and start and stop workers, all from the assistant you already talk to.
Delivery where people live Results land in email, Slack, Teams, Telegram, Discord, Notion, or SMS and WhatsApp, where their readers already are, instead of waiting in a chat nobody opens.
Auditable trails Every run leaves a typed event stream, liveness heartbeats, owner and self scores, and the allow or redact outcome of each tool call underneath it.

MCP connections

WorkerKit for your fleet. Knowledge for your reports.

Use WorkerKit to discover kits, build workers and manage your fleet. Add Knowledge to search published worker reports. Both use the same sign-in or key.

Mount	Address	What it carries
WorkerKit (default)	`https://mcp.workerkit.ai/workers`	Discover and install kits, build workers, and run and manage your fleet. Choose the full profile or a focused decision profile. Connect with OAuth or a bearer key.
Knowledge	`https://mcp.workerkit.ai/knowledge`	Company Knowledge: 6 tools to search and read published worker reports and track changes. Admins manage publication and reader access. Uses the same sign-in or key.

Area	Tools	What it covers
Continuous Learning	`worker_quality_get, worker_quality_set, worker_quality_preview`	Read criteria, three gates and availability reasons; save reviewed settings with expectedRevision; preview samples without a run. The worker dashboard offers owner-reviewed activation and a quoted AI draft when criteria are missing. Paid comparisons, diagnosis, monitoring, apply/rollback and company/shadow learning stay owner-only. Manager keys can disable any gate, but cannot enable automatic/shared learning. Kit install leaves all gates off.
Key	`key_info`	What your key is and exactly which scopes the other tools will honour. Call it first.
Fleet	`workers_list, worker_get, worker_set_enabled`	Every worker with live run state, one worker in full, and start or stop.
Apps and workers	`worker_permissions_get, worker_permissions_set, worker_bindings_get, worker_bindings_set`	What a worker may touch, in the same vocabulary a kit is written in, and its grants to call other workers: read both, replace its app set (account Admin) and fill, re-point or clear its worker grants. The writes need manageAppsAndWorkers; rules, identities and MCP tool bindings stay in the dashboard.
Runs	`worker_run, run_bulk, worker_runs, run_get, run_events, run_transcript, run_cancel, run_score, run_clear_digest`	Trigger a run with a prompt for that run, or one prompt across up to 20 workers; watch it step by step, read the receipt and the stored process log, cancel or grade it. On a decision worker it decides instead and acts on what it routes: sourceArgs and maxItems narrow and cap what is judged, and waitSeconds waits for the settled receipt, which carries the per-item decisions.
Fleet activity	`runs_feed, fleet_pulse, fleet_health, account_usage, activity_feed, activity_summary, account_spend`	Worker runs, app calls and configuration changes, activity counts, everything running now, fleet health, account headroom and spend by worker, day and model.
Two-way runs	`run_question, run_answer`	A run that needs an answer ends by asking; the answer starts a linked follow-on run.
Memory	`memory_get, memory_add, memory_update, memory_delete`	The rules and facts a worker carries into every run.
Schedules	`schedules_list, schedule_create, schedule_update, schedule_delete, worker_timezone_set`	When a worker starts on its own, and the time zone it works in: its local dates, its report times and the clock its daily schedules follow.
Instruction	`instruction_get, instruction_set, instruction_versions, instruction_version_get, instruction_restore`	The standing instruction, versioned on every change, with the history to compare against and roll back to. On a decision worker it reads the routing table and the install questions instead, and writes their answers.
Deliveries	`delivery_list, delivery_channels, delivery_create, delivery_update, delivery_secret_rotate, delivery_delete`	Where a run report goes when the worker finishes: email, Slack, Teams, Telegram, Notion, Discord, SMS or a signed webhook.
Deployment	`models_list, deployments_list, deployment_get, worker_deploy, deployment_update, worker_undeploy`	What makes an installed worker actually run: pick its model from the priced catalog, cap its spend, pause or resume it, take it off again. A worker with no deployment fires no schedule and refuses a run with not_deployed.
Budgets	`budget_get, budget_set, fleet_budget_get, fleet_budget_set`	A worker’s spend and run ceilings, and the account-wide fleet ceiling. Their own scope, because raising a dollar cap is the one management action that can cost money.
Creation	`worker_clone_preview, worker_clone, worker_clone_bulk`	Clone a worker into new ones, singly or in bulk, with a dry run first. A clone carries only permissions a person already approved on the source.
Deletion	`worker_delete`	Remove a worker for good, with its sub-workers. Permanent, where stopping one is not — which is why it is a scope of its own.
Kits	`kit_install_preview, kit_install`	Preview a directory kit against your account, then install it as a new worker — with deploy set, in the same call, which is what makes it run.
Kit authoring	`kit_validate, kit_publish, kit_update, kit_replace, kit_unpublish, kit_relist, kit_make_private, kit_delete, kit_scan_get, my_kits_list, publisher_get_mine, publisher_set`	Validate a kit in one dry run that reports every gate at once, publish it from content or from a worker you own, keep it private or list it, and keep your publisher profile. A private kit installed with kit_install is how an agent builds a worker from scratch.
Connected apps	`apps_list, app_connect, app_disconnect, app_github_accounts, app_github_repos, app_github_branches, app_slack_workspaces, app_slack_conversations`	Which apps an operator can use right now, in the kit vocabulary, and connecting the rest by credential: validated live, stored encrypted, never returned. Browser sign-ins stay on the Apps page. The GitHub and Slack lookups find repository and channel IDs for an install (discoverAppResources).
Model keys	`model_keys_list, model_key_set, model_key_delete`	Your own model-provider API keys, so runs bill your provider account instead of the wallet.
Onboarding and wallet	`onboarding_get, wallet_get, wallet_checkout_create, wallet_checkout_get`	Check model funding, hand off BYOK setup, inspect wallet balance, and request a human-confirmed Stripe checkout. A purchase is complete only when its status is credited.
Custom MCP servers	`mcp_servers_list, mcp_server_get, mcp_server_create, mcp_server_discover, mcp_server_set_tools, mcp_server_delete`	An app the platform does not offer, reached through its MCP server: register it as your own custom MCP app with its credential in the same call, enable the tools a job needs, and bind it in a kit.
API apps	`api_apps_list, api_app_get, api_app_create, api_app_update, api_app_validate, api_app_preview, api_app_publish, api_app_version_get, api_app_version_revoke`	Account-private API apps: validate and preview a definition offline, create and update drafts, publish immutable versions and revoke them. Authoring needs a live account Admin and managePrivateApiApps; connections and worker bindings are configured in the dashboard.
Decision authoring	`decision_worker_create, worker_decision_set`	Compile typed questions and a supported source recipe into a private kit and installed decision worker. Optional deploy; never starts a run. Requires createWorkers, plus manageDeployments when deploying. Retry the same requestId and body to recover the receipt. worker_decision_set attaches, replaces or removes a hybrid worker's classifier.
Action workers	`action_worker_options, action_worker_create, worker_tools, worker_tool_call, worker_tool_invocation`	Selected app tools with no model, called one at a time with exact inputs. Create with createWorkers; call and read receipts with invokeActions. A write needs an idempotencyKey; never resend an outcome_unknown call.
Support	`support_request_create`	Contact support about an error you cannot fix, a bug, an app request or a question. Returns a PE-XXXXXX reference.
Discovery and authoring reads	`workerkit_about, directory_overview, kits_search, kit_get, kit_app_tools, kit_authoring_guide, kit_vocabulary`	Public reads also available on the workers connection. Discover classification sources with kit_app_tools(purpose:"decision") and read kit_authoring_guide(section:"decision"). These reads never forward the manager bearer upstream.
Company Knowledge	`knowledge_sources, knowledge_search, knowledge_get, knowledge_changes, knowledge_configuration_get, knowledge_configuration_set`	On the separate mcp.workerkit.ai/knowledge mount, with the same key: discover, search and read published worker reports, reconcile changes, and configure sharing as an admin. Access follows publication and reader grants.

The manager key holds no app credentials: workers reach apps under their own grants and firewall, and no prompt can widen that. With readRuns or invokeActions the key can read what those workers return, including an Action worker's tool results.

Your fleet is also available from other MCP clients and the REST API.

Classification on demand

Create a decision worker from your questions.

Categorize, score or triage connected data, then reuse and adjust the worker.

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 createWorkers; 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 includes fleet management, app resource discovery, kit authoring and public directory reads. 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 the smaller workflow tool set. 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, Action worker 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.

App tools, no model

Call app tools through an Action worker.

One exact app operation per call, with the inputs you supply.

An Action worker (modelType: "none") exposes 1 to 64 selected app tools and has no model, instruction, schedule or deployment. Each call invokes one tool with the arguments the caller sends, under the worker's own app access, and readiness.canInvoke on worker_get says whether its tools can be called now. Run and deploy requests answer 400 action_worker_requires_invoke.

On the workers connection's full profile: action_worker_options lists apps with no tools selected; pass an explicit app for schemas and defaults (readWorkers). action_worker_create requires an explicit app or actionSpec and copies the selected app's default tools, or takes an actionSpec of 1 to 64, plus a slackConnectionId for Slack tools when the account has more than one Slack bot (createWorkers); worker_tools lists the saved tools (readWorkers); worker_tool_call calls one with arguments, plus an idempotencyKey on a write (invokeActions); worker_tool_invocation reads a write's receipt (invokeActions). Pass the returned tokenId. kits_search(modelType:"none") finds Action kits; install one with kit_install and no deploy.

An explicit actionSpec needs no app and can span native or reviewed MCP apps. Private API tools require a dashboard binding to a published version; they are not actionSpec refs.

A write tool (readOnly: false) needs an idempotency key. Repeating the key with the same arguments returns the stored receipt (a confirmation, not the app's response) without calling the app again; with other arguments it is a 409. A call answers with status succeeded, denied, failed, in_progress or outcome_unknown; branch on it, not on the HTTP code. On outcome_unknown the write may have happened: never resend it automatically, under any key; read the receipt and check the app. Each call counts toward the worker's daily request limit; a refusal marked retryable, such as usage_limit, is retried later under a new key. Only the owner changes the selected tools, in the dashboard.

Read the call examples.

Access and control

Scoped per worker, and scoped for Microsoft Copilot too.

Layer	What it holds
Per-worker grant	You connect each account yourself and choose what the worker may do there: per-app operations, read-only by default, narrowed by rules such as contact blocks, label and folder rules, customer-domain limits, time windows and IP allowlists. An account-level ceiling caps what any worker can be granted.
The app firewall	Every tool call is checked against the grant and the rules, field-masked, scanned for sensitive data, redacted, rate-limited and logged with its outcome. The worker's model never sees what the rules removed.
Prompt injection	A worker steered by content it reads still cannot exceed its grant. Proposed memory waits for a human. Publishing a kit to the directory runs a supply-chain and prompt-safety scan that fails closed.
The assistant's own access	A manager key carries explicit scopes, is shown once and stored hashed. No scope gives it app credentials, but invokeActions returns an Action worker's tool results, so grant it only where an agent should call those tools. An agent reads its scopes before planning, and an admin can revoke the key at any time without touching a worker.

A worker is only as trustworthy as the access behind it, so the access is yours to give, to narrow and to take back, one worker at a time. You delegate without handing over the kingdom.

How it connects

One MCP tool, added in Copilot Studio.

In a Copilot Studio agent: Tools, then Add a tool, then New tool, then Model Context Protocol. Fill in Server name, Server description and Server URL, then choose the authentication type. The fleet mount takes API key, with Type set to Header and a header name you enter yourself.

That last field is where this door differs from most: Microsoft lets the maker name the header, and publishes no list of names it accepts. Enter Authorization, and give the connection the value Bearer followed by the manager key, scheme and space included, since the fleet mount reads the scheme off that header. If the tenant will not take that header name, the OAuth 2.0 option on the same screen is the other way in: the fleet mount is an OAuth 2.1 authorization server, and the setup guide says which address it has to allow before a Copilot Studio connection can register against it.

The whole procedure, written for the agent doing it, is the setup guide. The human's part is the tool, the connection and one publish.

To reach it from Microsoft 365 Copilot, publish the agent to the Teams and Microsoft 365 Copilot channel. There is no field inside the Copilot chat app for an MCP server URL and no setting that turns one on: the agent is the only route in, which is why the setup guide ends with a publish rather than a paste.

The same fleet answers from anywhere else you work: any other MCP client, the wk CLI in a terminal, and the REST API for hosts that speak plain HTTPS. The fleet outlives the choice of assistant.

Cost: WorkerKit has a Free plan with no card required. Runs bill model tokens at the provider list price with no markup, from a prepaid wallet or your own provider key, inside the budgets you set. Connecting Microsoft Copilot is not a paid feature, and the plans are on the pricing page.

Questions

Microsoft Copilot and WorkerKit, answered.

Which Copilot is this, and where do I set it up? Microsoft Copilot Studio, at copilotstudio.microsoft.com, inside the agent you want to give the fleet to: Tools, then Add a tool, then New tool, then Model Context Protocol. Microsoft 365 Copilot itself has no field anywhere for an end user to paste an MCP server URL, and neither does the consumer Copilot app. The route into Copilot is the agent: build it in Copilot Studio, publish it to the Teams and Microsoft 365 Copilot channel with Make agent available in Microsoft 365 Copilot selected, then type @ in Copilot and pick it.
Do I have to paste a key anywhere? Yes. Connect https://mcp.workerkit.ai/workers with API key authentication and a manager key from workerkit.ai/fleet-access. Set the Authorization header value to Bearer followed by your key. The setup guide also covers OAuth.
Which header name do I use, and will Authorization work? Use Authorization with the value Bearer followed by your key. Microsoft documents a custom header name but does not explicitly list Authorization as accepted. If your tenant rejects it, use the OAuth alternative in the setup guide, which requires an allowed redirect URI.
Can Copilot read my email or CRM through WorkerKit? Only through workers you set up. The key inside that connection is a manager key with no app credentials, but run results (with readRuns) and an Action worker's tool results (with invokeActions) can include data from the apps that worker was granted. Choose the worker's app access and the key's scopes together. Copilot also keeps exactly the Microsoft Graph access the person signed in already had, which this connection neither widens nor reads.
What does the agent need to set this up? A Copilot Studio agent with generative orchestration on, because Microsoft states that generative orchestration is required to use MCP at all. A WorkerKit account with admin access, and a manager key created at workerkit.ai/fleet-access. The WorkerKit skill file at workerkit.ai/microsoft-copilot/SKILL.md, whose contents go into the agent's Instructions field. Reaching Copilot Studio itself needs a Copilot Studio license, a Microsoft 365 Copilot license, or membership of the authors security group, and a trial license can build and test but cannot publish.
What can an admin block, and what does the tenant have to allow? Three gates, and none of them is WorkerKit's. MCP access in Copilot Studio rides Power Platform connectors, so a tenant data policy over connectors also governs this server and its tools, and an admin can block it outright. Publishing the agent to everyone in the organization is a submission for admin approval rather than a maker decision; sharing it with named people by link is not. And the tenant has to allow Power Platform apps in Teams before the agent can be installed there at all. If any of the three is closed, nothing is broken on the WorkerKit side: the mount is public and the manager key is the only credential involved.
How does the agent get a worker's results? Two paths, and neither keeps a Copilot session open. The agent reads runs itself: runs_feed across the fleet, run_get for one run, and each receipt carries the closing report, the typed digest when the run produced one, and the settled cost. The worker also delivers on its own, to whichever channels are set on it: email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook. Teams is one of them, so a report can land in the same place the agent answers from.
I connected it and the fleet is empty. What now? Nothing is broken. An account has no workers until someone installs a kit or clones one, and the reads answering at all is the proof that the wiring and the key are good. A kit is a ready-made worker: its instruction, its exact app permissions and its schedule, written in advance. Open one at workerkit.ai/kits and install it from the page, which asks no scope of the key. With installKits on the key the agent can do it without leaving Copilot: kits_search to shortlist, kit_install_preview to show exactly what the new worker would be allowed to touch, kit_install when you approve.
What does it cost? The WorkerKit side starts free and asks for no card: 5 workers, 500 tool calls a day, and the whole safety layer. A run pays for its model tokens at the provider list price with no markup, against a prepaid wallet or a provider key of your own, and stops at the per-worker and fleet ceilings you set. Giving an agent the fleet costs nothing here. Copilot Studio is licensed and metered separately on Microsoft's side, which WorkerKit neither sets nor sees.

The setup guide is written for the agent doing the work, the MCP server page holds the surface behind it, and the wk CLI reaches the same fleet from a terminal.

To build a kit of your own, how to build a kit walks the procedure, and the kit-authoring skill is the file an agent keeps for it.