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., "@mcp-teams Pull up unread messages from my Teams channels"
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.
A safe-by-default Model Context Protocol server for Microsoft Teams, over Microsoft Graph. It lets an agent read and operate Teams — list joined teams, channels and members, read channel messages and threaded replies, read 1:1/group chats and their messages, and (in higher modes) post to channels, reply in threads, send chat messages, and soft-delete a message.
Browser sign-in: on first run it opens your browser to the Microsoft sign-in page, then caches the token and refreshes it silently — the server never sees your password.
Part of the dockndevai MCP server suite — one governance model across all of them.
The server starts read-only (see Safe by default); higher-capability tools are only registered when you raise the mode.
Tool | For | Needs mode |
| confirm which account is in use | read-only |
| teams the user has joined | read-only |
| channels in a team | read-only |
| members of a team | read-only |
| recent messages in a channel | read-only |
| one channel message + body | read-only |
| a channel message's thread | read-only |
| the user's 1:1 / group chats | read-only |
| messages in a chat | read-only |
| post to a channel | read-write + |
| reply in a channel thread | read-write + |
| send a chat message | read-write + |
| soft-delete your own message | admin + |
Related MCP server: teams-mcp
npx -y @dockndevai/mcp-teamsYou need an Entra (Azure AD) app registration. For the default browser sign-in, register a public client and add the redirect URI http://localhost (platform: Mobile and desktop applications), then use its Application (client) ID as TEAMS_CLIENT_ID. Grant delegated Team.ReadBasic.All, Channel.ReadBasic.All, ChannelMessage.Read.All (and ChannelMessage.Send / Chat.ReadWrite to post). No client secret is needed for interactive use.
{
"mcpServers": {
"teams": {
"command": "npx",
"args": ["-y", "@dockndevai/mcp-teams"],
"env": {
"TEAMS_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
"TEAMS_TENANT_ID": "common",
"TEAMS_MODE": "read-only"
}
}
}
}On first use the server opens your browser to sign in and caches the token at ~/.mcp-teams/token.json (0600); later runs refresh silently.
See docs/CLIENTS.md for Claude Code / Cursor / Codex / VS Code / Windsurf snippets, and .env.example for every supported variable.
Auth mode is chosen automatically (override with TEAMS_AUTH):
interactive (default) — only TEAMS_CLIENT_ID set. Authorization-code + PKCE with a loopback redirect: the browser opens, you approve once, and the access + refresh token are cached on disk. Most Teams messaging APIs are delegated-only, so this is the primary mode. The server never handles your password.
client-credentials (app-only) — TEAMS_CLIENT_SECRET present; the server fetches an app token itself. Note that several Teams message APIs are not available to app-only tokens without protected-API approval from Microsoft.
token — TEAMS_TOKEN set to a pre-obtained Graph bearer token. You manage its lifetime.
The access model is enforced by src/security.ts — defence in depth on top of the Graph token's own scopes/roles:
TEAMS_MODE — read-only (default) → read-write → admin. A tool is registered only if the mode allows its capability. Read-only exposes the 9 read tools; posting needs read-write; deletes need admin.
TEAMS_ALLOW_SEND — posting a message is visible to others and can't be silently un-posted, so on top of read-write it also requires this flag.
TEAMS_ALLOW_DELETE — deletes require this flag on top of admin mode. Deletes are soft-deletes (recoverable), and only your own messages.
TEAMS_TEAM_ALLOWLIST / TEAMS_PROTECTED_TEAMS — confine which teams can be posted to / moderated; mark teams that may be read but never posted to.
Interactive confirmation — when the client supports MCP elicitation, posting and deleting pause and ask the human to approve the exact target before running; clients that can't elicit fall back to the TEAMS_ALLOW_SEND / TEAMS_ALLOW_DELETE gates.
TEAMS_DRY_RUN — validate and log writes without executing them.
TEAMS_AUDIT_LOG — a JSON audit line per guarded operation, on stderr (default on).
See SECURITY.md.
npm install
npm run build
# introspect the tool list without signing in (uses a fake token, no network):
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | TEAMS_TOKEN=x node dist/index.js
npm testMIT
Fetch a single channel message by id, with its full body and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | Team id (from list_teams) | |
| channel_id | Yes | Channel id (from list_channels) | |
| message_id | Yes | Message id (from list_channel_messages) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds that the response contains 'full body and metadata', which is useful but does not disclose behavior such as not-found handling, error conditions, or permission requirements.
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 a single, direct sentence with no filler. It front-loads the core verb and resource, then specifies the result in a compact and useful way.
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 fetch operation backed by complete schema descriptions and safety annotations, the description is sufficient. It states the purpose and result, while the schema covers parameter details, and annotations cover behavioral safety.
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 description coverage is 100% and all three parameters are already described with their sources. The description adds the general notion of fetching 'by id' but not additional 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 uses a specific verb ('Fetch') and resource ('a single channel message by id'), and clearly distinguishes itself from the sibling list operations by emphasizing 'single' and including 'full body and metadata'. An agent can immediately tell this tool retrieves one message rather than a list.
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 phrase 'a single channel message by id' clearly communicates when to use this tool: when a specific message id is known and the full message body/metadata is needed. It does not explicitly name alternatives like list_channel_messages, but the contrast between 'single' and the sibling list tools 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 top-level messages in a channel, most recent first. Returns compact summaries (id, from, created, body, webUrl). Use list_message_replies for a message's thread.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Maximum messages (capped by TEAMS_MAX_RESULTS) | |
| team_id | Yes | Team id (from list_teams) | |
| channel_id | Yes | Channel id (from list_channels) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns compact summaries with specific fields (id, from, created, body, webUrl) and orders results most recent first. It doesn't mention pagination or the top parameter's cap, but the schema covers top's maximum. A 4 is appropriate because the description adds meaningful behavioral detail 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?
Two sentences, front-loaded with the core action and ordering, then the return format, then the sibling routing. 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 read-only list tool with full schema coverage and annotations covering safety, the description is nearly complete. It could mention pagination or the TEAMS_MAX_RESULTS cap behavior, but the schema already documents top's maximum and the description gives the return shape. Minor gap, so 4 rather than 5.
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 description coverage is 100%, so the schema already documents all three parameters. The description adds the 'most recent first' ordering and the compact summary fields, which indirectly clarifies what top controls, but it doesn't add new parameter-level meaning beyond the schema. Baseline 3 is correct.
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 lists top-level messages in a channel, most recent first, and distinguishes it from list_message_replies for thread replies. It names the specific resource (channel messages) and the verb (list), making it easy for an agent to select correctly among siblings.
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 explicitly says to use list_message_replies for a message's thread, providing a clear alternative and when-not-to-use condition. It also implies this is for top-level messages only, which is a clear usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the channels in a team, with their ids, display names, and membership type (standard/private/shared).
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | Team id (from list_teams) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the output fields but no additional behavioral context such as pagination, filtering, or access requirements. With strong annotations, this is acceptable but not exceptional.
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?
One sentence with no wasted words, and the core action and resource are front-loaded before the field list. Every part of the description 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?
For a simple list operation with one parameter and annotations covering the behavioral profile, the description is nearly complete. It names the return fields despite the lack of an output schema, but it does not mention edge cases like empty teams or access errors, which keeps it from a 5.
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 description coverage is 100% and the single parameter team_id is described as 'Team id (from list_teams)', which clarifies its origin. The description adds no further parameter meaning beyond the schema, so the baseline 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 states a specific verb ('List'), a clear resource ('channels in a team'), and lists the returned fields (ids, display names, membership type). It clearly distinguishes itself from sibling tools that deal with chats or 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 gives no guidance on when to use this tool versus alternatives like list_chats or get_channel_messages. The mention of 'in a team' and the team_id parameter imply a use case, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the messages in a 1:1 or group chat, most recent first. Returns compact summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Maximum messages (capped by TEAMS_MAX_RESULTS) | |
| chat_id | Yes | Chat id (from list_chats) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, non-destructive operation, so the description only needs to add non-obvious behavior. It does: newest-first ordering and compact summaries rather than full message content. This is useful beyond what annotations provide.
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?
One clean sentence that front-loads the operation, scope, ordering, and return format. Every element earns its place; there is no filler or repetition of the title/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?
Complexity is low: two parameters, a complete schema, and safety-oriented annotations. The description supplies the missing response shape ('compact summaries') and ordering. It stops short of detailing what the summaries contain, but that is not required for correct selection and invocation.
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 description coverage is 100%, with both parameters documented: chat_id's source and top's cap. The description adds no meaningful parameter-level detail, so the baseline 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?
States a specific verb ('List'), a precise resource ('messages in a 1:1 or group chat'), and gives ordering ('most recent first') plus output nature ('compact summaries'). The '1:1 or group chat' wording clearly separates it from sibling tools like 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?
Conveys the chat context and implies the prerequisite of a chat id (reinforced by the schema's 'from list_chats'). It does not explicitly name alternatives like list_channel_messages or list_message_replies, but the chat-vs-channel distinction is enough for a competent agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signed-in user's 1:1 and group chats (id, topic, type, last updated). Use a chat id with list_chat_messages.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Maximum chats (capped by TEAMS_MAX_RESULTS) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful context about the return fields and scope, which is consistent with the annotations, but does not add much behavioral detail beyond that.
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?
Two concise sentences, each earning its place: the first states the action, scope, and output fields; the second gives a direct usage pointer to the related messages tool. No filler or 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 low-complexity read-only tool with one optional parameter)Skip, full schema coverage, and rich annotations, the description is complete. It states the input scope, output fields, and how to use the result (chat id with list_chat_messages).
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 description coverage is 100%: the only parameter, top, is fully described in the schema as 'Maximum chats (capped by TEAMS_MAX_RESULTS)'. The tool description does not add further parameter detail, but with full schema coverage the baseline 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 uses a specific verb ('List') and resource ('the signed-in user's 1:1 and group chats') and enumerates the returned fields. This clearly distinguishes it from sibling tools like list_channels or list_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?
It explicitly identifies the signed-in user's chat scope and tells the agent to use a chat id with list_chat_messages, giving a clear next step. It does not explicitly contrast with sibling tools like list_channel_messages, but the context is strong enough for correct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the replies in a channel message's thread, most recent first.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Maximum replies (capped by TEAMS_MAX_RESULTS) | |
| team_id | Yes | Team id (from list_teams) | |
| channel_id | Yes | Channel id (from list_channels) | |
| message_id | Yes | Parent message id (from list_channel_messages) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral detail of ordering ('most recent first'), which is not in annotations. This is valuable and does not contradict any annotation.
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 a single, compact sentence with no filler. The main purpose is front-loaded, and every word earns its place. It is concise without sacrificing clarity.
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 list tool with fully documented parameters and safe read-only annotations, the description is complete. It does not explain return format, but that is not required since there is no output schema and the tool's behavior is straightforward. No missing information would prevent correct invocation.
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 description coverage is 100%, meaning all four parameters (top, team_id, channel_id, message_id) have their own descriptions in the input schema. The tool description does not add any parameter-specific information, but the schema already handles this. Baseline 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 states a specific verb ('List'), a specific resource ('replies in a channel message's thread'), and an ordering detail ('most recent first'). It clearly distinguishes from siblings like list_channel_messages (which lists channel messages, not replies) and get_channel_message (single message). The purpose is unambiguous.
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 when to use the tool: when you need replies to a specific message. However, it does not explicitly mention alternatives or exclusions (e.g., 'use list_channel_messages for channel-level messages'). The context is clear, but there is no explicit when-not guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the members of a team (display name, email, roles).
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | Team id (from list_teams) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds value by enumerating the returned fields (display name, email, roles). It does not mention pagination or empty-result behavior, but given the annotations, this is acceptable.
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 a single sentence with no wasted words. It front-loads the action and resource and lists the returned fields concisely, making it easy to scan.
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 full schema coverage and safety annotations, the description is adequate. It specifies the output fields, and the parameter is self-explanatory. It does not explain return format or edge cases, but these are not critical for such a simple 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?
The single parameter team_id is fully documented in the schema with a description referencing list_teams. The tool description itself adds no parameter details beyond the schema, but since schema coverage is 100%, a baseline 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 the action (list) and resource (members of a team), and specifies the returned fields (display name, email, roles). This distinguishes it from siblings like list_teams and list_channels without ambiguity.
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 discuss alternatives or exclusions, but the purpose is unambiguous: it is the tool for retrieving team members. The schema parameter description ('Team id (from list_teams)') implicitly guides usage by tying it to a prerequisite sibling, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the teams the signed-in user is a member of, with their ids, display names, and descriptions. Start here to get a team id for list_channels.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description need not repeat safety. It adds value by specifying the scope (only teams the user is a member of) and the output fields, which are not inferable from the schema (which is empty). 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 two sentences with no fluff. The first sentence states the purpose and output, the second provides a practical entry-point hint. Every word 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?
For a simple read-only, parameterless tool with annotations covering safety and an absent output schema, the description covers the essential points: what it returns and how to use it in a workflow. It lacks details like pagination or error handling, but these are minor for such a straightforward 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?
The tool has zero parameters, so schema coverage is trivially 100%. The baseline for a parameterless tool is 4; the description doesn't need to add parameter details, and it doesn't introduce any confusion.
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 lists teams the signed-in user is a member of, with specific fields (ids, display names, descriptions). The phrase 'Start here to get a team id for list_channels' distinguishes it from sibling tools by positioning it as the entry point for channel listing.
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 gives a concrete usage scenario ('Start here to get a team id for list_channels'), which implies when to use it in a workflow. It does not explicitly contrast with other siblings like list_team_members or list_chats, but the entry-point hint is sufficient guidance for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the signed-in user's identity (display name, user principal name, id). Use this to confirm which account the server is operating as before reading or posting.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific return payload, which is useful behavioral context beyond what annotations convey. It does not repeat or contradict 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?
Two concise sentences with zero filler. The main action and return fields are front-loaded, and the usage guidance is placed second. Every word 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?
For a zero-parameter, read-only tool with no output schema, the description fully covers what an agent needs: what it returns, why to call it, and that it is safe. The sibling tools are all list/read operations, and this is the only identity tool, so no additional context is missing.
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?
The tool takes zero parameters, so the schema coverage is trivially 100% and there is nothing for the description to document. The baseline for zero-parameter tools is 4, and the description does not need to add parameter details.
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 states a specific verb (return), a clear resource (the signed-in user's identity), and enumerates the exact fields returned (display name, user principal name, id). This unambiguously differentiates it from the sibling list/read tools, which all operate on other resources.
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 explicitly tells the agent when to use it: 'Use this to confirm which account the server is operating as before reading or posting.' This gives a clear context and intent, making the usage obvious even without mentioning alternatives (none of the siblings provide identity).
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.
v0.1.0get_channel_messagelist_channel_messageslist_channelslist_chat_messageslist_chatslist_message_replieslist_team_memberslist_teamswhoamiScored across 9 tools
Each tool targets a distinct Teams entity and action: identity, teams, channels, members, channel messages, replies, and chats. The potentially similar message tools are clearly separated by scope (channel vs. chat vs. reply) and by singular vs. plural retrieval.
The naming is overwhelmingly consistent with a list_* / get_* verb-noun pattern. The main deviation is whoami, which is a common standard command, and the distinction between list and get is semantically clear.
Nine tools is well-scoped for a read-only Microsoft Teams server. Every tool earns its place by covering a distinct read operation without unnecessary redundancy or bloat.
Core read workflows are covered well: identity, teams, channels, members, channel messages with replies, and chats. The main gaps are the lack of a full get_chat_message equivalent, no search capability, and no write actions, but these are workable for a listing-focused server.
Permissioned access to Outlook, OneDrive and Teams via the user's own Microsoft account
Read email/chat conversations, messages, contacts and teams; draft, send and update threads.
Governed app access for AI agents: 1,000+ apps & 12,000+ tools via Code Mode MCP.
Read calls, contacts, users, teams and numbers; tag calls and create or update contacts.
