Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Microsoft Teams MCP Server show my recent chats with limit 5"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives an AI agent access to Microsoft Teams via Microsoft Graph, using delegated, device-code authentication — the server acts as you, so it can only touch what your own Teams account can already see (least-privilege by default).
Built with the official MCP TypeScript SDK + MSAL. Runs locally over stdio.
Scope | Tools |
Messages |
|
Teams & channels |
|
Meetings & calendar |
|
Search & files |
|
Identity |
|
Every read tool supports response_format: "markdown" | "json" and a limit. Write tools (send_*, reply_*, create_*) are annotated non-read-only so clients can gate them.
Related MCP server: teams-mcp-server
You need an app registration in Microsoft Entra ID (Azure AD). You don't need to be a global admin to create it, but some delegated scopes are admin-restricted (see below).
Go to Entra ID → App registrations → New registration.
Name: Teams MCP (delegated)
Supported account types: Accounts in this organizational directory only (single tenant) is fine.
Redirect URI: leave blank.
On the new app, open Authentication →
Under Advanced settings, set Allow public client flows = Yes. (Required for device-code.)
Open API permissions → Add a permission → Microsoft Graph → Delegated permissions and add:
User.Read
Chat.ReadWrite
ChannelMessage.Send
ChannelMessage.Read.All (admin consent)
Team.ReadBasic.All
Channel.ReadBasic.All
Channel.Create
TeamMember.Read.All (admin consent)
Calendars.ReadWrite
OnlineMeetings.ReadWrite
Files.Read.All
Sites.Read.All
offline_access (usually added automatically)
Click Grant admin consent for the tenant. (The .All read scopes won't work without it. If you're not an admin, send your Teams/M365 admin this list to consent.)
Copy the Application (client) ID and your Directory (tenant) ID from the app's Overview page.
Why delegated, not application permissions? Application (app-only) permissions would grant the server org-wide read of every chat in the tenant — a large PHI/privacy blast radius and a harder security review. Delegated keeps the server scoped to your own access. If you later need unattended automation, add a client-credentials path then.
cd teams-mcp-server
npm install
npm run buildcp .env.example .env
# edit .env: set TEAMS_MCP_CLIENT_ID and TEAMS_MCP_TENANT_IDOr export the variables in your shell / MCP client config (below).
export TEAMS_MCP_CLIENT_ID=<your-app-client-id>
export TEAMS_MCP_TENANT_ID=<your-tenant-id> # or "organizations"
npm run loginYou'll see a message like "To sign in, use a web browser to open https://microsoft.com/devicelogin and enter the code XXXXXXXX." Complete it in your browser. The token cache (including a refresh token) is saved to ~/.teams-mcp-token-cache.json, so you won't need to do this again until the refresh token expires or is revoked.
Point your MCP client at the built server over stdio. Example client config:
{
"mcpServers": {
"teams": {
"command": "node",
"args": ["/absolute/path/to/teams-mcp-server/dist/index.js"],
"env": {
"TEAMS_MCP_CLIENT_ID": "<your-app-client-id>",
"TEAMS_MCP_TENANT_ID": "<your-tenant-id>"
}
}
}
}If no cached account exists, the first tool call triggers an interactive device-code login printed to stderr. Running npm run login first avoids that.
Use the MCP Inspector to exercise tools interactively:
npx @modelcontextprotocol/inspector node dist/index.jsStart with teams_whoami to confirm auth, then teams_list_joined_teams → grab a team_id → teams_list_channels, etc.
MSAL PublicClientApplication with the device-code flow.
Tokens + refresh token cached to disk (TEAMS_MCP_TOKEN_CACHE, default ~/.teams-mcp-token-cache.json, written 0600).
Each Graph call acquires a token silently from cache; only an expired/revoked refresh token forces a new device-code login.
Admin-restricted scopes: ChannelMessage.Read.All and TeamMember.Read.All require tenant admin consent. Without it those specific tools return a clear 403 with guidance.
Search uses the Microsoft Search API (/search/query, chatMessage entity) — relevance-ranked, not a literal grep.
Meetings are created as calendar events with isOnlineMeeting: true (Teams provider), which puts them on your calendar, invites attendees, and returns a join link.
Channel files resolve the channel's SharePoint filesFolder, then list its children.
Responses are truncated at 25,000 characters with guidance to narrow the query.
HIPAA note: this server can read message content that may contain PHI. It runs locally and holds no data beyond the on-disk token cache, but treat the host machine accordingly.
teams-mcp-server/
├── package.json
├── tsconfig.json
├── .env.example
├── README.md
└── src/
├── index.ts # entry point + `login` command
├── constants.ts # Graph base URL, scopes, limits
├── auth.ts # MSAL device-code + disk token cache
├── graph.ts # Graph request/pagination/error/format helpers
├── schemas.ts # shared Zod fragments
└── tools/
├── identity.ts # teams_whoami
├── teams.ts # teams & channels
├── messages.ts # chat + channel messaging
├── meetings.ts # meetings & calendar
└── search.ts # search + channel filesCreate a new channel in a team. This MODIFIES the team.
Args:
team_id (string): the team ID
display_name (string): channel name (1-50 chars)
description (string, optional): channel description
membership_type ('standard' | 'private'): default 'standard'
Returns: JSON { id, displayName, webUrl }.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | The Microsoft Teams team (group) ID. Get it from teams_list_joined_teams. | |
| description | No | Optional channel description | |
| display_name | Yes | Channel display name | |
| membership_type | No | Channel membership type | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation) and destructiveHint=false. The description explicitly states 'This MODIFIES the team,' which aligns with annotations but adds no further behavioral details such as authorization needs, rate limits, or side effects. Given annotations, this is adequate but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening sentence and a structured parameter list. However, the parameter list largely repeats schema details, which could be trimmed. Overall, it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes return format. It covers all parameters and the modification aspect. It lacks prerequisites or permission context but is generally complete for a creation tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents each parameter. The description lists parameters with types and defaults, adding limited value for parameters, but it also provides the return format 'Returns: JSON { id, displayName, webUrl }' which is not in the input schema or output schema (nonexistent), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new channel in a team.' The verb 'create' and resource 'channel' are specific, and the tool is easily distinguished from siblings like teams_list_channels (listing) and teams_send_channel_message (messaging).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. It only mentions 'This MODIFIES the team.' No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Microsoft Teams meeting as a calendar event on the user's calendar, with a Teams join link and (optionally) invited attendees. This CREATES an event and sends invitations.
Args:
subject (string): meeting title
start (string): ISO local date-time, e.g. '2026-07-02T14:00:00'
end (string): ISO local date-time, must be after start
time_zone (string): IANA/Windows time zone (default 'America/Chicago')
attendees (string[], optional): attendee email addresses
body (string, optional): meeting description / agenda
Returns: JSON { id, subject, joinUrl, webLink }.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| body | No | Optional meeting description/agenda | |
| start | Yes | ISO 8601 local date-time, e.g. '2026-07-02T14:00:00'. Interpreted in 'time_zone'. | |
| subject | Yes | Meeting subject/title | |
| attendees | No | Attendee email addresses to invite | |
| time_zone | No | Time zone for start/end | America/Chicago |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=false and destructiveHint=false, and the description confirms creation and invitation sending. It adds behavioral details like 'sends invitations' and the return format, which are not in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear top-level purpose sentence followed by a structured parameter list. Every line adds value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters (3 required) and no output schema, the description covers all necessary aspects: purpose, parameter semantics, return value shape, and behavioral effects. It feels complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 83% schema coverage, the description adds significant value beyond the schema: example ISO formats, explanation of local vs. UTC, default timezone, and optional fields. The schema itself is detailed, but the description enhances usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Create', the resource 'Microsoft Teams meeting as a calendar event', and key features (join link, optional attendees). This clearly distinguishes it from sibling tools like 'teams_create_channel' which creates a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool (to schedule a meeting), but does not explicitly mention when not to use it or provide comparisons to alternative tools. However, the context implies usage for meeting creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent messages from a 1:1 or group chat, newest first.
Args:
chat_id (string): the chat ID (from teams_list_chats)
limit (number, 1-50): max messages (default 20)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { count, messages: [{ id, from, createdDateTime, text, webUrl }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| chat_id | Yes | The chat (1:1 or group) ID (e.g. '19:...@thread.v2'). Get it from teams_list_chats. | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral details: newest first ordering, default limit, and response format options. No contradiction with annotations. It does not mention pagination or rate limits, but annotations cover the safety profile well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose, followed by Args and Returns sections. It is front-loaded with the main action and uses bullet points for parameters. No redundant sentences. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, all well-documented in schema, and no output schema, the description explains return structure (JSON with count, messages array with fields). This is fairly complete for a read-only tool. Missing error handling or pagination details, but acceptable given annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The description adds extra context: 'chat_id from teams_list_chats', 'limit max 50', and response_format enumeration. It summarizes parameter behavior succinctly, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read recent messages from a 1:1 or group chat, newest first.' The verb 'Read', resource 'recent messages', and scope are specific. It distinguishes from sibling tools like teams_list_channel_messages (for channels) and teams_send_chat_message (write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for obtaining the chat_id ('from teams_list_chats') and parameter defaults. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is clear but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a single calendar event, including the Teams join link and body preview.
Args:
event_id (string): the event ID (from teams_list_events)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON event object with subject, start, end, joinUrl, attendees, body preview.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Calendar event ID | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, etc. The description adds value by specifying exact returned fields (subject, start, end, joinUrl, attendees, body preview), compensating for no output schema. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with a clear structure, but the argument list format is slightly verbose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations and full schema coverage, the description is complete enough. It lists return fields despite no output schema, and specifies data sources. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds minor context: event_id origin and response_format default, but doesn't significantly expand beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb+resource ('Get full details for a single calendar event') and distinguishes from sibling 'teams_list_events' by noting inclusion of Teams join link and body preview. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the event_id comes from teams_list_events, guiding the agent's workflow. It lacks explicit when-not-to-use or alternative tools, but the context is sufficiently clear given siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and folders stored in a channel's Files tab (the channel's SharePoint-backed document folder).
Args:
team_id (string): the team ID
channel_id (string): the channel ID
limit (number, 1-50): max items (default 20)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { count, items: [{ id, name, type, size, webUrl, lastModifiedDateTime }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| team_id | Yes | The Microsoft Teams team (group) ID. Get it from teams_list_joined_teams. | |
| channel_id | Yes | The channel ID (e.g. '19:...@thread.tacv2'). Get it from teams_list_channels. | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds context about the source being the channel's Files tab and SharePoint backend, and specifies the return format. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first line, args in a list with default/range/enum info, and a return type line. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no output schema, the description provides a return structure ({ count, items: [...] }) which is complete. It covers all parameters and behavior. The context signals show low complexity, and the description fully addresses it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that team_id and channel_id can be obtained from other tools and by summarizing the parameter defaults and enums. It does not add new semantics beyond what the schema provides, but the extra context justifies a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'files and folders stored in a channel's Files tab'. It distinguishes from sibling tools that deal with messages or channels by specifying the file context and mentioning 'SharePoint-backed document folder'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on how to obtain required parameters (team_id, channel_id) via other tools, but does not explicitly compare with alternative tools for listing files. It implies usage for retrieving channel files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent top-level messages from a team channel, newest first.
Args:
team_id (string): the team ID
channel_id (string): the channel ID (from teams_list_channels)
limit (number, 1-50): max messages (default 20)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { count, messages: [{ id, from, createdDateTime, text, webUrl }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| team_id | Yes | The Microsoft Teams team (group) ID. Get it from teams_list_joined_teams. | |
| channel_id | Yes | The channel ID (e.g. '19:...@thread.tacv2'). Get it from teams_list_channels. | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds sorting ('newest first'), return format details, and output format options. It also mentions the limit parameter. This adds value beyond annotations, though it could specify that only top-level messages are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence for the action, followed by a bullet list of parameters and a return format description. No unnecessary words, front-loaded with the main operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description includes the return structure which is helpful. It covers all parameters and their sources. However, it does not mention pagination or behavior when no messages exist, and it could clarify that replies are not included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description restates parameter information in a readable format but does not add new semantic meaning beyond what the schema already provides (types, defaults, constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Read recent top-level messages from a team channel, newest first.' It uses a specific verb ('read') and resource ('top-level messages from a team channel'), and distinguishes from siblings like teams_get_chat_messages (chat vs channel) and teams_send_channel_message (write vs read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading messages, not sending or replying. It mentions top-level messages, which excludes replies. However, it does not explicitly name alternatives or state when not to use. Sibling tools provide context, but the description could be more direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List channels within a given team.
Args:
team_id (string): the team ID (from teams_list_joined_teams)
limit (number, 1-50): max channels (default 20)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { count, channels: [{ id, displayName, description, membershipType, webUrl }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| team_id | Yes | The Microsoft Teams team (group) ID. Get it from teams_list_joined_teams. | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent operation. Description adds details on return format and channel structure, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose stated first, then args in bullet format, then return format. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage, annotations, and no output schema, description includes return structure and parameter details, making it complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% covers parameter descriptions. Description adds extra context for team_id (source tool) and response_format options, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List channels within a given team' with specific verb and resource. Differentiates from sibling tools like teams_create_channel and teams_list_joined_teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (listing channels for a team) and hints at prerequisite (team_id from teams_list_joined_teams). Does not explicitly state when not to use, but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's recent 1:1 and group chats (not channel conversations).
Use this to find the chat_id for reading or sending chat messages.
Args:
limit (number, 1-50): max chats (default 20)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { count, chats: [{ id, topic, chatType, members }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds context about listing 'recent' chats and the return format, but no additional behavioral traits beyond what annotations provide. The description is consistent and adds minor transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences covering purpose, usage, and parameters/returns. It is front-loaded with the core function, followed by a usage hint, then structured argument details. Every sentence is essential and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description provides the return structure (JSON with count and chats fields). It covers input parameters well. However, it does not mention pagination, ordering, or any limits beyond the explicit 'limit' parameter, which could be needed for a complete understanding. Overall, it is sufficiently complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats parameter details (limit with range, response_format with enum) and adds context like default values and return structure, which adds some value but does not significantly extend beyond the schema. No examples or advanced usage are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List the user's recent 1:1 and group chats' and explicitly excludes channel conversations, effectively differentiating it from sibling tools like teams_list_channels. The verb 'List' and resource 'chats' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this to find the chat_id for reading or sending chat messages.' It also implicitly advises when not to use it by stating 'not channel conversations'. While it could explicitly mention alternatives, the context is sufficient for an agent to understand when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's upcoming calendar events (ordered by start time).
Args:
limit (number, 1-50): max events (default 20)
days_ahead (number, 1-90): look-ahead window in days (default 14)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { count, events: [{ id, subject, start, end, joinUrl, attendees }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| days_ahead | No | Look-ahead window in days | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. Description adds ordering by start time and return structure. However, it does not clarify timezone handling, pagination beyond limit, or if 'upcoming' includes events starting now.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short with two clear sentences plus parameter/return details. Every sentence adds value. Could be slightly more structured with bullet points, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a return format outline but omits details like meaning of 'count' (total vs filtered) and full structure of nested objects (e.g., attendees). For a simple tool, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description copies parameter details from schema without adding new meaning (e.g., defaults, ranges). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the user's upcoming calendar events (ordered by start time)', specifying the exact verb, resource, and ordering. It differentiates from sibling tools like teams_get_event (single event) and teams_create_meeting (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing upcoming events but does not explicitly compare to alternatives (e.g., when to use teams_get_event). No guidance on when not to use this tool or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Microsoft Teams the signed-in user is a member of.
Use this first to discover team IDs needed by channel/message tools.
Args:
limit (number, 1-50): max teams to return (default 20)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { count, teams: [{ id, displayName, description }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive nature. The description adds behavioral detail beyond annotations by specifying the return format (JSON with count and teams array) and parameter constraints (limit range and defaults).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: one sentence for purpose, one for usage guidance, then clear lists for args and returns. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no output schema, the description covers purpose, usage, return shape, and parameter details. It does not mention pagination behavior beyond a limit, but this is a minor gap for a straightforward tool. Annotations and sibling context provide additional completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description reiterates the defaults and return format but adds minimal additional semantic meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Microsoft Teams the signed-in user is a member of, with a specific verb and resource. It also explicitly mentions using it to discover team IDs needed by channel/message tools, distinguishing it from sibling tools like teams_list_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context to use this tool first to get team IDs for other operations, implying when to use it. It does not explicitly exclude scenarios, but the guidance is sufficient for a simple discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List members of a team, including their roles (e.g. 'owner').
Note: requires the delegated scope TeamMember.Read.All, which may need a one-time Entra admin consent.
Args:
team_id (string): the team ID
limit (number, 1-50): max members (default 20)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { count, members: [{ id, displayName, email, roles }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| team_id | Yes | The Microsoft Teams team (group) ID. Get it from teams_list_joined_teams. | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses required scope and admin consent, and return structure beyond annotations. Annotations already indicate read-only and idempotent; description adds permission context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose, and includes needed details. The note on scope is slightly secondary but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, permissions, parameters (with defaults), and return structure. Adequate for a simple list tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description repeats schema documentation without adding new meaning. The cross-reference to get team_id is already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists team members with roles. Distinct from sibling tools like teams_list_channels or teams_create_meeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides permission requirements (scope and admin consent) but does not explicitly guide when to use this tool versus alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an existing top-level channel message (adds to its thread).
Args:
team_id (string): the team ID
channel_id (string): the channel ID
message_id (string): the parent message ID (from teams_list_channel_messages)
content (string): the reply body (max 28000 chars)
content_type ('text' | 'html'): body format (default text)
Returns: JSON { id, webUrl } of the created reply.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Message text. Plain text by default; set content_type='html' to send HTML. | |
| team_id | Yes | The Microsoft Teams team (group) ID. Get it from teams_list_joined_teams. | |
| channel_id | Yes | The channel ID (e.g. '19:...@thread.tacv2'). Get it from teams_list_channels. | |
| message_id | Yes | Parent message ID to reply under | |
| content_type | No | Body content type: 'text' (plain) or 'html' | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) that is not destructive (destructiveHint=false). The description adds that it returns JSON with 'id' and 'webUrl', and specifies content length limit (28000 chars). This provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose in the first sentence. It then lists parameters in a structured Args block. While somewhat lengthy due to repetition of schema info, every sentence adds value (e.g., return format). Could be slightly more concise by omitting parameter details already in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, no output schema), the description is fairly complete: it covers core behavior, return format, and content type options. It does not address error handling or permissions, but with annotations and schema coverage, the agent has enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description's Args section repeats parameter info without adding new meaning (e.g., default content_type, length limits are already in schema). As per guidelines, baseline 3 is appropriate when schema covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reply') and the resource ('existing top-level channel message', adds to thread). It distinguishes from sibling tools like 'teams_send_channel_message' (which sends a new top-level message) and 'teams_send_chat_message' (chat reply).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (reply to an existing message) but does not explicitly state when not to use or provide alternatives. It lacks explicit guidance on prerequisites, though the schema parameter descriptions partially cover that. The context is adequate but could be improved with a note like 'use after teams_list_channel_messages to get the message_id'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across the user's Teams chat and channel messages using the Microsoft Search API. Returns matching messages with a snippet and a deep link.
Note: relevance-ranked full-text search; exact phrasing and recency affect hits.
Args:
query (string): the search text (e.g. 'Plaid key', 'HIPAA BAA')
limit (number, 1-50): max hits (default 20)
response_format ('markdown' | 'json'): output format (default markdown)
Returns: JSON { total, count, moreResultsAvailable, hits: [{ id, from, createdDateTime, snippet, webUrl }] }.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50) | |
| query | Yes | Search text | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for machine-readable | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds useful behavioral context about relevance-ranked full-text search, exact phrasing, and recency affecting hits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs and a bullet list. It front-loads the purpose and then provides details and return format. No redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema, annotations present), the description covers purpose, behavior, parameters, and return fields. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, so baseline is 3. The description adds value by providing concrete examples for the query parameter (e.g., 'Plaid key', 'HIPAA BAA') and clarifying defaults for limit and response_format, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across Teams chat and channel messages using the Microsoft Search API, returning matching messages with a snippet and deep link. This distinguishes it from siblings like teams_get_chat_messages or teams_list_channel_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching messages but does not explicitly state when to use this tool versus alternatives (e.g., teams_list_channel_messages for all messages in a channel). No exclusions or contextual guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a new top-level message to a team channel as the signed-in user.
Args:
team_id (string): the team ID
channel_id (string): the channel ID
content (string): the message body (max 28000 chars)
content_type ('text' | 'html'): body format (default text)
Returns: JSON { id, webUrl } of the created message.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Message text. Plain text by default; set content_type='html' to send HTML. | |
| team_id | Yes | The Microsoft Teams team (group) ID. Get it from teams_list_joined_teams. | |
| channel_id | Yes | The channel ID (e.g. '19:...@thread.tacv2'). Get it from teams_list_channels. | |
| content_type | No | Body content type: 'text' (plain) or 'html' | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructiveness. The description adds behavioral details: message creation, max 28000 chars, content type options, and returns a JSON with id and webUrl. It also specifies 'as the signed-in user', clarifying authentication context. Missing details like idempotency or error conditions, but overall good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action. The bullet list for args is clear, though it duplicates schema information. Every sentence is useful, but the duplication slightly reduces efficiency. Still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes the return format ({ id, webUrl }). It covers required parameters and constraints. It lacks error handling or rate limit info, but for a straightforward creation tool, it's reasonably complete. Could mention that replies require a different tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all parameters. The description's Args list largely repeats the schema info (e.g., max chars, default content_type). No additional semantic context beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Post a new top-level message to a team channel as the signed-in user.' It uses a specific verb (post) and resource (channel message), and distinguishes from siblings like teams_reply_channel_message (reply) and teams_send_chat_message (chat).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. The term 'top-level' implies it's not for replies, but there is no direct guidance on when not to use it or mention of sibling tools. The parameter descriptions indirectly provide context (e.g., where to get IDs), but the main description lacks clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a 1:1 or group chat. This POSTS a message as the signed-in user.
Args:
chat_id (string): the chat ID (from teams_list_chats)
content (string): the message body (max 28000 chars)
content_type ('text' | 'html'): body format (default text)
Returns: JSON { id, webUrl } of the created message.
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | Yes | The chat (1:1 or group) ID (e.g. '19:...@thread.v2'). Get it from teams_list_chats. | |
| content | Yes | Message text. Plain text by default; set content_type='html' to send HTML. | |
| content_type | No | Body content type: 'text' (plain) or 'html' | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive. Description adds that it POSTs as signed-in user. Does not disclose rate limits, idempotency, or side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line purpose, then bulleted args, then return description. Front-loaded with purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, required params, return format. Lacks error conditions or auth context, but given low complexity and good annotations, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds useful context: 'chat_id (from teams_list_chats)', content max 28000 chars, content_type default. Adds value beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sends a message to a 1:1 or group chat. Distinguishes from sibling 'teams_send_channel_message' by specifying chat type. Verb 'send' and resource 'chat message' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly guides usage by stating 'to a 1:1 or group chat', contrasting with channel messages. However, does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Microsoft 365 identity the server is authenticated as (delegated).
Use this to confirm which account the Teams MCP is acting on behalf of before sending messages or creating meetings.
Args: none.
Returns: JSON { id, displayName, userPrincipalName, mail, jobTitle }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds the return shape (JSON fields), which is helpful since no output schema exists. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three precise sentences covering purpose, usage, and format. Front-loaded with the primary action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and rich annotations, the description provides adequate return schema that is not in any structured output schema. Missing error handling details but acceptable for a simple identity query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description accurately states 'Args: none', which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Microsoft 365 identity the server is authenticated as, with a specific verb and resource. It distinguishes from sibling tools by focusing on identity introspection rather than data manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool before sending messages or creating meetings to confirm the acting account. This provides clear context for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0teams_create_channelteams_create_meetingteams_get_chat_messagesteams_get_eventteams_list_channel_filesteams_list_channel_messagesteams_list_channelsteams_list_chatsteams_list_eventsteams_list_joined_teamsteams_list_team_membersteams_reply_channel_messageteams_search_messagesteams_send_channel_messageteams_send_chat_messageteams_whoamiScored across 16 tools
Every tool serves a distinct purpose: creating channels, meetings, sending/receiving messages in channels and chats, listing resources, etc. No two tools overlap in functionality, so an agent can easily select the correct one.
All tools follow the exact pattern `teams_verb_noun` in snake_case. Verbs are uniformly imperative (create, get, list, reply, search, send, whoami), making the set predictable and easy to navigate.
With 16 tools, the server covers the core Teams operations (team/channel management, messaging, meetings, events, files) without unnecessary bloat. The number is well-proportioned to the domain.
The surface enables most everyday workflows: reading and writing messages in channels and chats, listing teams/channels/members/events/files, creating channels and meetings, and searching. Minor gaps like updating or deleting messages or channels are absent, but the core is solid.
Permissioned access to Outlook, OneDrive and Teams via the user's own Microsoft account
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
OAuth 2.1 short-link tools for AI agents with scoped tokens, approvals, audit logs, and revocation.
Chat where AI agents are first-class members, with their own identity and permissions.
