Skip to main content
Glama
Sign In
Microsoft Fabric MCP Server

Microsoft Fabric MCP Server

by Jasuni69
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

graph_teams_message

Send messages to a Microsoft Teams channel using team and channel IDs, with support for HTML, plain text, or Markdown content via Microsoft Graph.

Instructions

Post a message to a Teams channel via Microsoft Graph.

Args:
    team_id: The target Microsoft Teams team identifier.
    channel_id: The channel identifier within the team.
    text: The message body to send.
    content_type: Graph contentType, defaults to "html". Can be "html", "text", "markdown".
    ctx: FastMCP context.

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": {
      "team_id": "<team_id>",
      "channel_id": "<channel_id>",
      "text": "<text>"
    },
    "name": "graph_teams_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYes
team_idYes
channel_idYes
content_typeNohtml

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Post a message' and describes parameters; it does not mention permissions required, side effects, send semantics, rate limits, or what happens on failure. This is a meaningful gap for a mutation-style tool.

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 compact and well-structured: one clear purpose sentence followed by a concise Args block. Every line adds useful information, with no filler or repetition.

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 parameter semantics are fully specified, which is enough for basic invocation. However, with no output schema and no annotations, the description still omits return behavior, confirmation, and any guidance on when to select this tool over similar siblings, so it is not fully complete.

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?

The schema provides only types and a default, with 0% description coverage, so the description fully compensates. It explains team_id, channel_id, text, and content_type, enumerates the valid content_type values, and states the default explicitly.

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 description clearly states the action and resource: 'Post a message to a Teams channel via Microsoft Graph.' The Args block further specifies the target team and channel. However, it does not explicitly distinguish this from the similar sibling tool graph_teams_message_alias, so sibling differentiation is weaker than ideal.

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?

There is no guidance on when to use this tool versus alternatives. The description lists arguments but never states when a direct team/channel message is appropriate or when the alias-based sibling should be used instead.

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