Skip to main content
Glama

List scheduled messages

list_scheduled_messages
Read-only

Lista as mensagens agendadas pendentes da conta (as que ainda vão sair), com o contato, o texto e quando sai. Filtra por telefone se informado. As que o cliente respondeu antes, com "cancelar se responder", já saem da lista.

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": "list_scheduled_messages"
  }
}

Input Schema

NameRequiredDescriptionDefault
phoneNoOpcional: só as do contato com esse número.
target_user_idNoID da conta-alvo (opcional; APENAS o admin da plataforma pode usar). Padrão: a conta autenticada.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover readOnly/destructive safety, and the description adds genuinely non-obvious behavior: messages answered by the customer under a 'cancel if replied' rule are excluded from the result set. That prevents the agent from concluding messages are missing or from trying to cancel them here. It still says nothing about result limits or ordering.

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?

Three short sentences, front-loaded with the resource and scope, followed by filtering and the exclusion caveat. The parenthetical gloss '(as que ainda vão sair)' earns its place by disambiguating 'agendadas'; no filler sentences.

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?

With no output schema, the description compensates by naming the returned fields, and with only two optional parameters plus read-only annotations, little else is required. The missing piece is any indication of result volume/pagination, minor for a pending-queue listing.

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 both parameters are already documented. The description only restates the phone filter ('Filtra por telefone se informado') and says nothing about target_user_id or its admin-only restriction, which lives solely in the schema. Baseline 3 applies when the schema carries the semantics.

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?

States a concrete verb and resource ('Lista as mensagens agendadas pendentes da conta') and immediately narrows scope to messages that have not yet gone out, plus what each row contains (contact, text, send time). It does not explicitly name a sibling (e.g. cancel_scheduled_message) to differentiate, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies the calling context ('pendentes... as que ainda vão sair') and says the phone filter is optional ('Filtra por telefone se informado'), but never states when to prefer this over cancel_scheduled_message or how to handle already-sent messages. Usage is inferable rather than spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources