Skip to main content
Glama

local-mcp

by com.local-mcp

Teams Send Message

teams_send_message

Sends a text message to a Microsoft Teams chat or channel. Requires Microsoft Teams to be running and signed in (token is read fresh from Teams' local cookies on each call). The chat_id MUST come from a previous teams_list_chats call — never fabricate ids. This is a write operation: the first call returns a preview, the second call (with confirm=true) actually sends. sent:true means the message was read back from the conversation (delivery verified) — trust THAT field, not a follow-up read: teams_search_messages and teams_read_chat_messages read Teams' own local sync index, which can lag a verified send by minutes (single observed case: 3 min, #2285). A zero-result sibling read right after sending is NOT evidence the send failed. A response with status "sent_unconfirmed" means the server accepted the POST but the message could NOT be verified — tell the user to open Teams itself and check before assuming the recipient was notified.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesPlain-text message body. Max 28000 chars. No formatting / mentions / attachments in v1.
chat_idYesThread id from teams_list_chats (e.g. '19:<uuid>_<uuid>@unq.gbl.spaces' for 1:1, '19:<uuid>@thread.tacv2' for group)
confirmNoMust be true to actually send. Without it, returns a preview without making any network call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only flag readOnlyHint=false and openWorldHint=true, which are minimal. The description adds the full write behavior: local cookie auth, Teams must be running, two-phase confirmation, verified vs unverified send status, and the sync-lag caveat for sibling reading tools. 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 long but information-dense; every major sentence covers a distinct operational necessity. It could arguably be trimmed (e.g., the specific 3-min case and issue number), but the detail serves a real functional purpose.

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 two-step confirmation, verification semantics, sibling-read lag, and presence of an output schema, the description covers all necessary operational context: prerequisites, expected behavior, failure modes, and how to trust results. No significant gap remains.

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 3 applies. The description adds critical semantics beyond the schema: chat_id must be sourced from teams_list_chats and never fabricated, and confirm must be true to send while first call returns a preview. This extra guidance elevates it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a clear verb and resource ('sends a text message to a Microsoft Teams chat or channel'). The title and description make the core function obvious, and the chat_id parameter ties it to teams_list_chats. However, it doesn't explicitly differentiate from the sibling teams_send_channel_message, and saying 'chat or channel' broadens scope beyond the chat_id parameter's actual channel semantics.

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 states the prerequisite that chat_id must come from teams_list_chats and never fabricated. It defines the two-step confirm workflow (preview then send) and explicitly warns that zero-result sibling reads after sending do not indicate failure, with a precise status sent_unconfirmed action. This is exemplary usage guidance.

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

All local-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation3/5

Many tools are clearly distinct per app (e.g., chrome_*, safari_*, m365_*), but there is notable overlap between generic file tools like `file_list` and `finder_list`, both listing files; `search_contacts` and `list_contacts` serve similar purposes; `report_friction` and `report_problem` both send feedback to the team. The large number of tools with similar purposes in different domains creates moderate ambiguity for an agent.

Naming Consistency4/5

The naming convention is very consistent overall: most tools follow a `{app}_action` or `verb_noun` pattern (e.g., `chrome_click`, `create_calendar_event`, `list_reminders`). There are minor deviations like `lmcp_install_upgrade` (two verbs) and `complete_omnifocus_task` vs. `complete_reminder` (inconsistent verb placement). Still, the pattern is predictable and readable across the full set.

Tool Count2/5

With 225 tools, the surface is extremely large and heavy. While it covers many distinct domains (browsers, mail, calendar, files, notes, reminders, video editing, web automation, etc.), the sheer number makes it hard to navigate and likely includes many rarely-used tools. This is far beyond the well-scoped range of 3-15 tools and feels excessive even for a 'local everything' MCP server.

Completeness3/5

For many app integrations, the tool set provides solid CRUD coverage (e.g., Calendar has create, read, update, delete; Apple Notes has create, read, update, list, search; OmniFocus has create, list, search, complete). However, some areas are incomplete: for example, there is no tool to create a new Mail folder or delete notes. The 'web' tools lack a clear update/delete for saved sessions. The suite is broad but has notable gaps within individual domains.

Resources