Skip to main content
Glama
nobrainer-tech

langflow-mcp-server

by nobrainer-tech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_monitor_messages

Query Langflow chat messages by flow, session, sender, or sender name. Page through history with limit and offset to inspect recent or older conversations.

Instructions

Query a window of chat messages filtered by flow, session, sender, or sender name. Langflow selects the newest 100 by default (maximum 200; limit 0 uses the default). Use offset to page into older history; order and order_by sort within the selected window.

Input Schema

NameRequiredDescriptionDefault
limitNoWindow size; omitted or 0 uses 100, upstream clamps values above 200
orderNoDisplay order within the selected window (default: ASC)
offsetNoMessages to skip from newest history (default: 0)
senderNoOptional sender identifier to filter messages
flow_idNoOptional flow ID (UUID) to filter messages by flow
order_byNoOptional field to order results by (default: timestamp)
session_idNoOptional session ID to filter messages by session
sender_nameNoOptional sender name to filter messages

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.12.3
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Window size; omitted or 0 uses 100, upstream clamps values above 200",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Messages to skip from newest history (default: 0)",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / order
      Added value: +{
+  "description": "Display order within the selected window (default: ASC)",
+  "enum": [
+    "ASC",
+    "DESC"
+  ],
+  "type": "string"
+}
  2. First observedv4.11.0

TDQS

A4.4/5.0
Behavior4/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 does well: it discloses the default window size, the upstream clamp at 200, the meaning of limit 0, and the paging direction of offset. It omits auth/permission requirements and return shape, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three sentences, each earning its place: purpose first, then window/limit semantics, then paging and ordering. No filler and no redundant restatement of the schema.

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?

For an 8-parameter read tool with no output schema, the description covers filtering, defaults, clamping, and paging adequately. It does not sketch the returned message shape, but with no output schema declared that omission is minor.

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% (baseline 3), and the description adds window semantics not obvious from the schema: that order/order_by sort within the selected window and that offset skips from newest history. That reinforces the interaction between limit, offset, and ordering beyond the field-level docs.

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 (Query) plus resource (window of chat messages) with the filter dimensions named (flow, session, sender, sender name). This clearly distinguishes it from sibling get_monitor_message (single message) and get_monitor_session_messages without needing schema inspection.

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?

Explains the default window (newest 100, max 200), how limit 0 behaves, and that offset pages into older history. It gives clear operational context but never names an alternative tool for fetching a single message or session-scoped listing, so routing guidance is incomplete relative to the sibling set.

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