Skip to main content
Glama
Sign In

Nilyo

by com.nilyo
OverviewDiscussionsAdmin

Facebook / Messenger: List recent messages

facebook_list_recent_messages
Read-onlyIdempotent

Read a bounded date-window digest from ONE explicitly selected Facebook personal/Page inbox. Enumerate requested inboxes separately. Preserve complete=false; never call a partial digest exhaustive.

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": {
      "inbox_id": "<inbox_id>",
      "after": "<after>",
      "include_sent": "<include_sent>",
      "chat_type": "<chat_type>",
      "max_chats": "<max_chats>"
    },
    "name": "facebook_list_recent_messages"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterYes
beforeNo
inbox_idYesExact inbox.id from facebook_list_inboxes, including PAGE_<page_id>_INBOX for a selected Page. Not a Page profile_id or connection account_id.
chat_typeYesall
max_chatsYes
account_idNoOwned Facebook unipile_account_id from list_connected_accounts. Not a Facebook person or Page ID. Required when several Facebook accounts exist.
include_sentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Adds substantive behavior beyond the read-only annotations: results are window-bounded and may be partial ('complete=false'), and the agent is told not to characterize a partial digest as exhaustive. The phrase 'Preserve complete=false' is cryptic without an output schema, and nothing is said about rate limits or pagination behavior.

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 operation's scope before the routing rule and the result-fidelity caveat. The middle sentence ('Enumerate requested inboxes separately') is terse to the point of ambiguity, and 'Preserve complete=false' presumes response fields the reader has not seen.

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 7-parameter read tool with five required parameters, no output schema, and low schema coverage, the description covers scope and result fidelity but omits what comes back (chats with messages? flattened messages?), how max_chats truncates, and how before interacts with the required after. Those gaps are recoverable from parameter names but not from the prose.

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 only 29%, so the description should carry more; it reinforces the two riskiest semantics (a single inbox_id per call, date-window bounding) but says nothing about chat_type, max_chats, include_sent, or the before/after relationship. Those five parameters rely entirely on self-evident names and enum bounds.

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?

Uses a specific verb-plus-resource ('Read a bounded date-window digest') scoped narrowly to ONE selected Facebook personal/Page inbox, which separates it from the inbox-enumeration siblings. It does not however explicitly distinguish itself from facebook_list_inbox_chats or messaging_list_recent_messages, which an agent must still infer from their names.

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

Usage Guidelines4/5

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

'from ONE explicitly selected ... inbox' plus 'Enumerate requested inboxes separately' gives real routing guidance: first resolve a single inbox via facebook_list_inboxes, and never loop this tool over multiple inboxes. It stops short of saying which sibling to call when the goal is a chat-by-chat listing rather than a message digest.

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

All Nilyo toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources