Work IQ MCP: elva verktyg som ger agenten hela Microsoft 365

I Copilot Studio kopplar man verktyg till en agent. Work IQ MCP är ett av dem. Det ligger under Microsoft IQ och ger agenten tillgång till organisationens egen information: e-post, kalender, Teams, filer, möten och affärssystem, inom användarens behörigheter.

De flesta MCP-servrar växer i takt med det de täcker. En server för e-post får ett verktyg per operation, en för kalender likaså, och innan man vet ordet av har agenten sextio verktygsdefinitioner i kontexten som den ska välja mellan.

Work IQ gör tvärtom. Hela Microsoft 365 exponeras genom elva verktyg, och det antalet är tänkt att inte växa oavsett hur många arbetsbelastningar som tillkommer. Det är ett designval värt att förstå även om man aldrig ska röra Microsofts plattform, eftersom problemet det löser finns i varje MCP-integration.

Den här artikeln går igenom hur det fungerar, vad de elva verktygen gör, och varför nästan allt är skrivskyddat tills någon aktivt ändrar det. Underlaget är Microsofts dokumentation plus två egna mätningar: en direkt mot Work IQ:s MCP-endpoint, och en i en Copilot-agent med Work IQ anslutet. Vill du först förstå runtimen som allt detta körs i finns GitHub Copilot harness inifrån.

Vad Work IQ är

Microsoft IQ är samlingsnamnet för fyra lager: Work IQ för hur anställda arbetar, Fabric IQ för verksamhetens livestatus, Foundry IQ för kuraterad institutionell kunskap, och Webb-IQ för omvärlden.

Work IQ är alltså arbetsplatslagret. Det låter agenter komma åt, förstå och agera på organisatorisk data i Microsoft 365 och externa system, med behörighetsanpassad styrning inbyggd. Det når man genom tre standardprotokoll: A2A för agent till agent, MCP för verktygsbaserad åtkomst, och REST för vanliga request-svar-anrop.

Två saker är värda att veta direkt, eftersom de ofta överraskar.

“Microsoft 365 Work IQ is read only unless an administrator explicitly turns on write operations in the Microsoft 365 admin center.”

Källa: Work IQ in Microsoft Copilot Studio

En detalj som är lätt att missa i licensdiskussioner: Work IQ kräver inte en Microsoft 365 Copilot-licens. Det erbjuds med användningsbaserad debitering, och kostnader och styrning hanteras centralt i Microsoft 365 admin center.

Designprincipen är det intressanta

Tre principer bär hela konstruktionen, och de är formulerade tillräckligt tydligt för att gå att låna.

“Fewer tools, more paths. Generic tools operate on resource paths. New workloads add paths, not tools - the tool surface never grows.”

Källa: Work IQ MCP overview

Principen om policy framför scopes förtjänar en fotnot. Microsoft skriver att fyra breda OAuth-behörigheter styr kapabiliteten, men behörighetsreferensen listar i skrivande stund en enda: WorkIQAgent.Ask, delegerad, med administratörsmedgivande, beskriven som “read and write access to Microsoft 365 resources that are accessible to Work IQ agents”. Spärren mot skrivning sitter alltså inte i behörigheten utan i tenantens policy.

I praktiken betyder det att fetch /me/messages läser e-post, do_action /me/sendMail skickar ett mail, och create_entity /me/events skapar en kalenderpost. Samma handfull verb, olika sökvägar. Microsofts egen formulering är att WorkIQ entity paths borrow from the conventions of Microsoft Graph, så den som kan Graph känner igen sig direkt.

De elva verktygen

När Work IQ kopplades in som MCP-server i en Copilot-agent gick agentens kapabiliteter från 123 till 146, och antalet inbyggda verktyg från tolv till 23. De elva tillkommande är dessa, sammanfattade på svenska. Verktygens egen text, ordagrant, kommer i nästa avsnitt.

De två sista är markerade för att de är de viktigaste att förstå. Det är dem hela introspektionsprincipen vilar på, och de är också de enda som är svåra att gissa sig till.

Verktygens egna ord

Ett MCP-verktyg består av två delar: ett schema som beskriver parametrarna, och en beskrivning i klartext. Beskrivningen är inte dokumentation för dig. Den är prompten modellen läser när den avgör om verktyget passar, och den är enda stället där Microsoft kan lägga in regler som agenten följer i stunden.

Därför är de värda att läsa. Så här lyder beskrivningen av fetch, ordagrant från tools/list:

“Fetch one or more WorkIQ entities by path. Use entity paths discovered from ask responses or well-known paths like /me/messages. Returns JSON array with results for each path. WorkIQ entity paths borrow from the conventions of Microsoft Graph. Always include a $select query parameter with only the fields you need to reduce response size (e.g., /me/messages?$select=id,subject,from). For collection endpoints, include $top to limit results (e.g., /me/messages?$select=id,subject&$top=10). Some APIs do not support $top (e.g., /me/chats/{id}/members) — omit $top for those. Use the get-schema tool to discover available fields if unsure. For file content (documents, images, photos — e.g. /content or $value endpoints), use fetch_blob instead.”

Ungefär halva texten är instruktioner snarare än beskrivning. Samma mönster går igen: search_paths pekar vidare till fetch_blob, do_action och create_entity säger åt agenten att köra get_schema först, och update_entity varnar för att vissa sökvägar ersätter hela entiteten. Verktygsbeskrivningen är den plats där Work IQ styr agentens beteende, och den är skriven för en modell som läser fort.

Ibland blir det motsägelsefullt. I do_action är jsonBody markerad som obligatorisk i schemat, medan beskrivningen av samma fält börjar med versalerna “OPTIONAL — some actions require a body”. I search_paths och get_schema finns fält som schemat kallar valfria och beskrivningen kallar “Required.” En agent som litar på schemat och en agent som litar på texten gör alltså olika saker.

Serverns namn och version kommer ur dess eget svar på initialize, liksom protokollversionen. En detalj värd att känna till för den som bygger mot endpointen: Microsoft skriver att MCP-klienter upptäcker autentiseringen via /.well-known/oauth-protected-resource, men den sökvägen svarar 400 BadRequest med meddelandet “Invalid request, no valid route.”

En observation: det är elva, inte tio

Microsofts översiktssida beskriver Work IQ MCP som tio generella verktyg, och kategoritabellen summerar till tio: sex entity, två copilot och två schema.

Verktygsreferensen inleder likadant, ordagrant: “The Work IQ MCP server exposes 10 tools.” Sedan dokumenterar samma sida elva stycken, med fullständig parametertabell för var och en. fetch_blob finns alltså i referensen, men saknas i räkningen och i kategoritabellen.

En anslutning mot endpointen ger elva. Principen om få verktyg står sig alltså, men siffran gör det inte. Använd elva om du visar den observerade verktygslistan, och tio om du citerar Microsofts kategorisering. Blanda dem inte.

Så används de i praktiken

Några mönster återkommer i hela verktygsreferensen, och de är den sortens saker som avgör om en integration fungerar eller blir gissningslek.

Börja alltid med get_schema. Innan create_entity, update_entity eller do_action behöver du veta vilka fält som är obligatoriska. Vet du inte ens vilken sökväg som finns börjar du ett steg tidigare, med search_paths och ett reguljärt uttryck som .*calendar.*.

Alla sökvägar är relativa. Ingen bas-URL, någonsin.

Begränsa alltid det du hämtar. Verktygsreferensen är uttrycklig med att $select ska användas med bara de fält du faktiskt behöver, exempelvis /me/messages?$select=id,subject,from. För samlingar begränsar $top antalet. Vissa endpoints stödjer inte $top, till exempel /me/chats/{id}/members.

Etags är inte valfria vid uppdatering. Deklarerar schemat If-Match måste den sättas till @odata.etag från din senaste läsning av samma entitet. Vissa sökvägar ersätter dessutom hela entiteten, vilket betyder att alla obligatoriska fält måste skickas med, inte bara de du ändrar.

“If the operation's schema declares an If-Match header parameter, you MUST set it to the @odata.etag value from the latest read of the same entity.”

Källa: inputschemat för update_entity och delete_entity. Parametern headers finns inte i Microsofts verktygsreferens.

Filer går inte genom fetch. För filinnehåll används fetch_blob. Gränsen på 4 MB gäller råfilen och är en standardgräns som kan konfigureras per sökväg. En fil som överskrider den ger ett verktygsfel som innehåller den gällande gränsen, inte något innehåll.

Ett genomgående mönster till: tio av de elva verktygen tar en valfri agentId för att rikta anropet mot ett specifikt agent-ID, och undantaget är list_agents, som inte tar några parametrar alls. För ask är standardvärdet bizchat-as-gpt-scenario. Här skiljer sig källorna åt: Microsofts verktygsreferens kallar agentId “Reserved for future use” på de flesta verktygen, medan schemat som endpointen returnerar säger “Optional agent ID to target a specific agent”.

De fyra komponenterna bakom verktygen

Verktygen är bara en av fyra delar. De övriga tre förklarar varför Work IQ är mer än ett API-omslag.

Chat är optimerat för agent till agent-samarbete och webbapplikationer, så att uppgifter kan delegeras och svar levereras sammanhängande. Context samlar och förankrar kontextuell data internt i Microsoft 365, vilket gör att agenter slipper hantera rådata eller bygga egna hämtningspipeliner. Tools är de elva verktygen. Workspaces använder SharePoint Embedded som beständigt arbetsminne inom tenantgränsen, där agenter kan spara mellanresultat, återanvända dem och lämna över uppgifter till andra agenter.

Workspaces är den minst omtalade och kanske mest intressanta. Ett delat arbetsminne innanför tenantgränsen är precis vad flerstegsprocesser över flera agenter brukar sakna.

Styrningen är poängen, inte en eftertanke

Work IQ ger agenten kontext från e-post, kalender, Teams, filer, möten och affärssystem. Det skapar uppenbara krav, och Microsoft har byggt styrningen därefter.

Policymotorn använder Rego från Open Policy Agent och utvärderar varje enskild begäran utifrån resurssökväg, metod, användaridentitet och innehåll. Alla åtgärder körs inom ramen för den specifika användarens behörigheter, och samtliga anrop loggas centralt för granskning, användaranalys, rate limiting och efterlevnad.

Policylagret slås på och av per tenant i Microsoft 365 admin center, under Agents och Tools, och en ändring kan ta upp till 24 timmar att slå igenom. I den första releasen finns ingen styrning per användare, per app eller per agent.

Som standard tillåts sökvägar under /me/, /users/ och /sites/, medan /authentication/ och /servicePrincipals/ är blockerade. Mutationer är avstängda: create, update, delete och åtgärder som skickar e-post kräver att en administratör slår på dem.

En detalj som är lätt att missa: “Policy approval doesn't guarantee the operation succeeds.” Ett anrop som policyn släpper igenom kan ändå falla på användarens egna behörigheter.

Här finns en slutsats som är lätt att gå miste om. Governance för den nya upplevelsen går inte att förstå enbart genom traditionell DLP i Power Platform. När Copilot Studio börjar använda tjänster som Work IQ blir Microsoft 365 admin center och Agent 365 centrala delar av modellen, och de sitter någon annanstans än där Power Platform-administratören är van att titta.

De äldre servrarna finns kvar

Vid sidan av Work IQ MCP:s generella verktyg finns fortfarande separata servrar per arbetsbelastning. De är fler och mer specifika, vilket är precis den utveckling som principen om få verktyg är tänkt att undvika.

Räknar man ihop bara dessa sex landar man på 104 verktygsdefinitioner för ungefär samma yta som Work IQ MCP täcker med elva. Det är den konkreta skillnaden mellan att lägga till verktyg och att lägga till sökvägar.

Det finns en praktisk anledning att bry sig utöver elegansen: MCP-servrar räknas mot det totala antal verktyg en agent kan hosta, och antalet servrar som kan köras samtidigt i en konversation är begränsat. Microsofts egen rekommendation är kort och tydlig.

“MCP-servrar räknar mot det totala antalet verktyg en agent kan hosta ... håll antalet anslutna servrar litet och ta bort servrar du inte längre använder.”

Källa: Verktyg i Copilot Studio

Sammanfattning

Work IQ är Microsofts svar på en fråga som varje MCP-bygge ställs inför förr eller senare: vad gör man när ytan man vill exponera är större än det som får plats i en verktygslista.

Fyra saker att ta med sig:

• svaret är verb plus sökvägar, alltså få verktyg som opererar på många paths, i stället för ett verktyg per operation
• introspektion vid runtime via get_schema och search_paths ersätter att ladda in tusentals typdefinitioner
• allt är skrivskyddat tills en administratör aktivt slår på skrivning i Microsoft 365 admin center
• styrningen ligger delvis utanför Power Platform, vilket gör att traditionell DLP inte räcker som mental modell

Vill du se runtimen som Work IQ kopplas in i finns GitHub Copilot harness inifrån. Vill du se var MCP passar in bland de andra verktygstyperna, och vad allt kostar, finns nya Copilot Studio. För grunderna i agentbegreppen finns AI-agenter och agentiska system.

---

Om underlaget. Verktygslistan, parametrarna och de citerade beskrivningarna hämtades 2026-08-19 direkt från tools/list mot Work IQ:s MCP-endpoint, alltså verktygens egna scheman ordagrant. Att samma elva verktyg med samma parametrar exponeras för en agent i Copilot Studio bekräftas av en separat mätning i en Copilot-agent med Work IQ anslutet. Övriga uppgifter kommer från Microsofts dokumentation, kontrollerad samma dag. Work IQ i Copilot Studio är en förhandsversion, så räkna med att detaljer ändras.