Skip to main content
Glama

Prévoir un message pour plus tard

ficiel_schedule_message
Destructive

Programme l'envoi d'un message texte dans une conversation existante, à une date et une heure choisies. Portée « write » requise. Exactement le mécanisme du bouton « Prévoir ce message » du composer (même table, même réveil, même annulation automatique si le contact répond avant l'heure) : aucune différence entre un message programmé via MCP et un message programmé à la main. Un seul message programmé à la fois par conversation (annulez l'existant avec ficiel_cancel_scheduled pour le remplacer). Le destinataire nommé (recipient) est vérifié TOUT DE SUITE, à la programmation : un message prévu part tout seul le moment venu, se tromper de cible ici ne se rattraperait pas. Les autres garde-fous d'un envoi immédiat s'appliquent à l'HEURE PRÉVUE, pas à la programmation : un refus (plafond du canal, tag bloquant) survient alors et annule le message, visible dans ficiel_list_scheduled.

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": {
      "text": "<text>",
      "send_at": "<send_at>",
      "recipient": "<recipient>"
    },
    "name": "ficiel_schedule_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesTexte du message.
channelNoCanal : requis avec lead_id ; avec conversation_id, sert seulement de vérification.
lead_idNoIdentifiant du contact (lead_id), avec channel. Inutile si conversation_id est donné.
send_atYesDate et heure d'envoi, ISO 8601 AVEC fuseau (ex. 2026-08-31T10:06:00+02:00). Entre 1 minute et 2 mois dans le futur.
recipientYesOBLIGATOIRE : le destinataire tel que vous le nommez — nom affiché, @pseudo Instagram ou LinkedIn, numéro pour WhatsApp, nom du groupe pour une conversation de groupe. Le serveur le compare au contact réel de la cible avant tout envoi (casse et accents ignorés ; le nom complet, le prénom seul ou le pseudo exact suffisent). Si Ficiel ne connaît AUCUNE identité pour ce contact (ni pseudo, ni nom, ni numéro), indiquez exactement « sans nom » : c'est la façon de dire que vous assumez l'absence de vérification. Omettre le champ reste refusé. En cas de désaccord, l'envoi est refusé (recipient_mismatch) et rien ne part.
conversation_idNoIdentifiant de la conversation (conversation_id). Recommandé.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / text / description
      Previous value: -"Texte du message. Avec voice_id, c'est le texte à prononcer."New value: +"Texte du message."
    • removedInput schema / properties / voice_id
      Removed value: -{
      -  "description": "Identifiant d'une voix de votre organisation (voir ficiel_list_tags_and_stages, section voices) pour un vocal généré. Omis = message texte.",
      -  "type": "string"
      -}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the timing model: recipient identity is verified immediately at scheduling, while other guardrails (channel cap, blocking tag) fire at send time and cancel the message, visible in ficiel_list_scheduled. It also states equivalence with the manual composer button, including automatic cancellation if the contact replies first — behavior an agent could not infer from destructiveHint/openWorldHint alone.

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 purpose, then consequences, then constraints — well ordered. It is dense and somewhat long (parentheticals and caps emphasis), but nearly every clause carries operational information; only minor tightening would improve it.

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

Completeness5/5

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

For a destructive, non-idempotent, open-world write tool with no output schema, the description covers the failure modes (mismatch, cap, blocking tag), where to see the outcome (ficiel_list_scheduled), and the replacement path (ficiel_cancel_scheduled). Nothing essential for a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning for `recipient`: immediate comparison against the contact's real identity, accent/case insensitivity, partial-name matching, the special « sans nom » escape hatch, and the recipient_mismatch refusal. It does not expand on send_at bounds or the channel/lead_id pairing beyond what the schema already says.

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

Purpose5/5

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

States a specific verb (programme l'envoi), resource (message texte), and scope (dans une conversation existante, à une date/heure choisies). It clearly separates itself from ficiel_send_message by naming the delayed-send mechanism, so an agent can pick it without opening the schema.

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

Usage Guidelines5/5

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

Explicit when-to-use context (planned deferred send in an existing conversation, requires write scope) plus an explicit constraint and alternative: only one scheduled message per conversation, cancel the existing one with ficiel_cancel_scheduled to replace it. It also routes the agent to ficiel_list_scheduled to observe refusals.

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.