Local MCP

Teams Read Chat Messages

teams_read_chat_messages

Read-only

Reads the most recent messages of a Microsoft Teams chat (chat_id from teams_list_chats), oldest first, from Microsoft 365. Deleted messages are skipped; a system event (a member added, a call) shows as [kind]. Times are ISO 8601 in this computer's time zone, with its offset (2026-10-11T14:05-03:00). body is the whole message up to 20,000 characters; a longer one is cut there and its row has body_truncated: true. Reads at most 20 pages of 50 messages, deleted ones included. When the read is cut (by that bound, or because the call ran out of time) the answer has truncated: true. Needs a work or school Microsoft 365 account connected with connect_m365_account (personal Microsoft accounts have no Teams reads). When no Microsoft 365 account is connected at all, it reads the Teams app's local cache on this Mac instead (needs Full Disk Access, can be hours or days behind); the answer's source says which one answered (graph or local_cache).

Input Schema

Name	Required	Description
`limit`	No	Max items to return (default 50)
`account`	No	Which connected Microsoft 365 account to use: its email (UPN), its id from list_m365_accounts, or its display name when unique. Leave it out to use the default account.
`chat_id`	Yes	Chat ID from teams_list_chats

Output Schema

Name	Required	Description
`note`	No
`count`	No
`error`	No
`source`	No	Which source answered: graph (Microsoft 365) or local_cache (the Teams app's cache on this Mac, used only when no Microsoft 365 account is connected).
`account`	No	The email (UPN) of the Microsoft 365 account this call used.
`fix_tool`	No
`messages`	No
`truncated`	No	Present and true only when the read was cut before it had everything it was asked for.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026
- addedOutput schema / properties / messages / items / properties / body_truncated
```
Added value: +{
+  "type": "boolean"
+}
```

Changed2 schema fields changedOct 10, 2026

addedOutput schema / properties / fix_tool
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / source

Added value: +{
+  "description": "Which source answered: graph (Microsoft 365) or local_cache (the Teams app's cache on this Mac, used only when no Microsoft 365 account is connected).",
+  "enum": [
+    "graph",
+    "local_cache"
+  ],
+  "type": "string"
+}

Changed5 schema fields changedOct 5, 2026

addedInput schema / properties / account

Added value: +{
+  "description": "Which connected Microsoft 365 account to use: its email (UPN), its id from list_m365_accounts, or its display name when unique. Leave it out to use the default account.",
+  "type": "string"
+}

changedInput schema / properties / limit / description

Previous value: -"Max messages (default 50)"New value: +"Max items to return (default 50)"

addedOutput schema / properties / account

Added value: +{
+  "description": "The email (UPN) of the Microsoft 365 account this call used.",
+  "type": "string"
+}

addedOutput schema / properties / note
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / truncated

Added value: +{
+  "description": "Present and true only when the read was cut before it had everything it was asked for.",
+  "type": "boolean"
+}

Changed1 schema field changedJul 30, 2026

changedInput schema / properties / chat_id / description

Previous value: -"Chat ID from list_teams_chats"New value: +"Chat ID from teams_list_chats"

First observedJun 30, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well past the readOnly/openWorld annotations: message ordering (oldest first), deleted messages skipped, system events rendered as [kind], 20,000-character body cutoff with body_truncated, a 20-page x 50-message ceiling with a truncated flag, and a documented degraded local-cache path requiring Full Disk Access and possibly stale by hours or days. Timestamp format and zone are also disclosed. 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?

Front-loads what is read and the ordering, then layers truncation, the page bound, auth requirements, and the cache fallback. Dense and purposeful, though a few clauses are packed into long sentences that could be split for scanning.

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?

Covers everything an agent needs to call it correctly and interpret the answer: auth prerequisites, degraded-mode behavior, truncation semantics, and the source discriminator. With an output schema present it correctly avoids describing return values in detail while still flagging the fields that change interpretation.

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 limit, account, and chat_id, making 3 the baseline. The description adds real meaning for account by noting personal accounts cannot read Teams and that the answer's source field reveals which backend served it, but says nothing extra about limit beyond the schema's default.

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?

States a specific verb and resource ("Reads the most recent messages of a Microsoft Teams chat") and pins the resource scope with "chat_id from teams_list_chats", which separates it from teams_read_channel_messages and teams_search_messages. An agent can identify the tool and its target without opening the schema.

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?

Gives clear operating conditions: requires a work/school M365 account via connect_m365_account, personal accounts don't work, and with no account connected it falls back to reading the local Teams cache. It does not explicitly name when to prefer teams_read_channel_messages or teams_search_messages, so alternatives are only implied by the resource scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Local MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.