Skip to main content
Glama

webex_list_direct_messages

List 1:1 direct messages with a Webex person by ID or email; optionally filter by thread and include attachment metadata.

Instructions

List 1:1 DM messages; personId or personEmail required.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "webex_list_direct_messages"
  }
}

Input Schema

NameRequiredDescriptionDefault
parentIdNoThread parent ID
personIdNoDM person ID
personEmailNoDM person email
includeFileDetailsNoInclude attachment metadata; 1 HEAD request/file

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: no indication of read-only safety, permissions, pagination, result ordering, or rate limits. 'List' implies a read, but the agent gets no confirmation of side-effect profile or result volume.

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?

Two compact clauses with the resource scope front-loaded and the precondition second; nothing is wasted. It is efficient, though the terseness borders on under-specification rather than optimal structure.

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?

For a four-parameter read tool with full schema coverage and no output schema, the description covers the resource and the key identifier requirement. It omits pagination/result limits and the distinction from the general message-listing tools, which an agent still needs to choose correctly.

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 baseline is 3. The description does add one genuinely useful fact the schema omits: the schema declares zero required parameters, yet the description states a person identifier is required, correcting a real ambiguity. It does not explain parentId or includeFileDetails semantics, so it stays at 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 description names a specific verb and resource ('List 1:1 DM messages'), which lets an agent distinguish this from space-message siblings like webex_get_messages. It does not explicitly name an alternative, but the '1:1 DM' scope is concrete enough to identify the operation.

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?

The only guidance is a parameter precondition ('personId or personEmail required'), not a when-to-use rule. Nothing tells the agent when to pick this over webex_get_messages, webex_search_messages, or how to handle a DM with someone not yet in a space.

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