Microsoft Teams MCP Server

by adkins-amdg

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.2/5 across 16 of 16 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![teams-mcp-server MCP server](https://glama.ai/mcp/servers/adkins-amdg/teams-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/adkins-amdg/teams-mcp-server)

Score Badge

Copy to your README.md:

[![teams-mcp-server MCP server](https://glama.ai/mcp/servers/adkins-amdg/teams-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/adkins-amdg/teams-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adkins-amdg/teams-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server