Skip to main content
Glama

microsoft_list_team_channels

Read-onlyIdempotent

List Microsoft Teams channels within a specified team using the authenticated connector account, providing read-only access to channel structure.

Instructions

Microsoft connector operation list_team_channels (platform tool microsoft.list_team_channels).

Routes only through the exact project/account governed connector authority.

Args: arguments: JSON string of arguments for the connector operation. project_id: Authenticated Project UUID. project_ref: Exact project correlation reference. connector_account_ref: Project-bound connector account alias. idempotency_key: Stable business-action identity. effect: Required and must be read; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
effectYes
argumentsNo{}
project_idNo
project_refNo
approval_refNo
idempotency_keyNo
connector_account_refNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.1
    • addedInput schema / properties / approval_ref
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Approval Ref"
      +}
    • addedInput schema / properties / connector_account_ref
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Connector Account Ref"
      +}
    • addedInput schema / properties / effect
      Added value: +{
      +  "const": "read",
      +  "title": "Effect",
      +  "type": "string"
      +}
    • addedInput schema / properties / idempotency_key
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Idempotency Key"
      +}
    • addedInput schema / properties / project_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Project Id"
      +}
    • addedInput schema / properties / project_ref
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Project Ref"
      +}
    • addedInput schema / required
      Added value: +[
      +  "effect"
      +]
  2. First observedv0.1.0

TDQS

C2.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some useful context about exact project/account connector routing and that effect must be 'read', but it does not disclose behavior beyond those basics. The mention of approval_ref 'when resuming a write' is confusing on a read-only tool, though it does not directly contradict 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably compact and uses a clear bullet structure for parameters. However, the first sentence is largely tautological, and much of the Args list duplicates schema property names with limited additional meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a connector wrapper with no operation-specific input schema descriptions, the description omits the most important information: how to specify the target team and what arguments are valid. It also does not distinguish this tool from the many sibling Microsoft list operations. The presence of an output schema helps return-value understanding, but the input side remains incomplete.

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 must carry the parameter semantics burden. The Args list gives high-level meanings for all seven parameters, which helps. However, the key 'arguments' parameter is only described as 'JSON string of arguments for the connector operation' with no indication of what fields the connector actually expects (e.g., team identifier, channel filters), so an agent still cannot reliably construct the call.

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

Purpose2/5

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

The description restates the tool name ('Microsoft connector operation `list_team_channels`') without actually explaining that it lists channels within a Microsoft Teams team. It adds a routing constraint, but not the core resource/action semantics or any differentiation from siblings like microsoft_list_teams or microsoft_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 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 alternative Microsoft list operations. The only contextual hint is that routing goes through the governed connector authority, but no conditions, exclusions, or alternative tool names are given.

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