Skip to main content
Glama
Sign In
chatwatch

chatwatch

by xxxxDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

teams_send_message

Sends text and optional local files to a Microsoft Teams chat, respecting each chat's send mode: auto-send, save as draft for approval, or block. Sending opens and marks the chat read.

Instructions

Send text, and optionally local files (absolute paths), to a chat. The chat's send mode decides: auto sends now (status sent), draft saves it for a person to approve (status draft), off refuses. not_sent: nothing went out, you may try again. maybe_sent: do not resend; ask a person to check the chat. Sending opens the chat, which marks it read.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "chat": "<chat>",
      "text": "<text>"
    },
    "name": "teams_send_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
chatYes
textYes
filesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does a lot of it: it discloses that delivery is mediated by a per-chat send mode, enumerates the resulting statuses (sent, draft, not_sent, maybe_sent), and warns about a side effect ('Sending opens the chat, which marks it read'). It still omits permission/auth requirements and any limits on attached files.

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-loaded with the action, then the mode/status semantics. Dense but each clause carries information. Some phrasing is terse to the point of being cryptic ('off refuses').

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 side-effecting send tool with no annotations and no output schema, the status taxonomy and the 'opens the chat, marks it read' caveat cover most of what an agent needs. The unresolved chat identifier format is the main remaining gap.

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 description coverage is 0%, so the description has to compensate. It explains that 'files' are local files given as absolute paths, which is a real gain, but 'chat' is never defined (id vs. name vs. thread) and 'text' gets no treatment beyond the verb. Partial compensation only.

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?

Opens with a specific verb and resource: 'Send text, and optionally local files (absolute paths), to a chat.' This clearly separates it from the read/list siblings (teams_read_messages, teams_list_chats, teams_get_attachments). It doesn't explicitly name a sibling to distinguish itself from, so the differentiation is implicit rather than stated.

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 concrete operational guidance in the form of send-mode behavior (auto/draft/off) and, critically, retry rules — 'not_sent: nothing went out, you may try again' and 'maybe_sent: do not resend; ask a person to check the chat.' That covers correct usage well, but it never states when to prefer this tool over a sibling or what prerequisites exist (e.g., auth, chat existence).

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

Deploy Server

Other Tools