nc-mcp-server

get_messages

Read-onlyIdempotent

Fetch chat messages from a Talk conversation, newest first, in compact one-line format. Supports pagination with before_message_id, thread filtering, and optional system messages to retrieve historical context.

Instructions

Get chat messages from a Talk conversation.

Returns messages in reverse chronological order (newest first). Uses a compact format: "[id] author: message text" - one line per message. Messages inside a thread are marked after the author: the thread's first message as '[id] author [thread ""]: text', the rest of the thread as "[id] author [thread ]: text".

IMPORTANT: Start with a small limit (20-50). If you need more context, use before_message_id with the oldest message ID from the previous call to paginate backwards through the history.

Args: token: The conversation token. Use list_conversations to find tokens. limit: Maximum number of messages to return (1-200, default: 50). Start small to avoid exceeding response size limits. before_message_id: Fetch messages older than this message ID (for pagination). Use the smallest message ID from a previous call. Default 0 means start from the newest message. include_system: Include system messages like "User joined", "Conversation created" (default: false - only chat messages). thread_id: Only return messages of this thread (default 0 = all messages, including thread messages). Use list_threads to find thread IDs.

Returns: Compact text with one message per line: "[id] author: message". The last line shows pagination info if more messages may exist. Empty when nothing matches, for example when there is nothing older than before_message_id.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`token`	Yes
`thread_id`	No
`include_system`	No
`before_message_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.0Sep 23, 2026
- addedInput schema / properties / thread_id
```
Added value: +{
+  "default": 0,
+  "title": "Thread Id",
+  "type": "integer"
+}
```
First observedv0.7.0Sep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral context beyond that: newest-first ordering, thread marking syntax, compact one-line-per-message formatting, pagination info on the last line, and empty results when nothing matches before_message_id.

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?

The description is long but every section earns its place: purpose and ordering up front, an important pagination warning, parameter details, and return format. The structure with Args and Returns makes it scannable despite the detail.

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 read-only message retrieval tool with rich annotations and an output schema, the description covers ordering, formatting, pagination, system messages, thread filtering, and empty-result behavior. Nothing critical is missing for an agent to invoke it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, but the description fully compensates by explaining every parameter: token requires list_conversations to discover, limit has range and usage strategy, before_message_id defines 'smallest message ID' pagination, include_system gives examples, and thread_id clarifies default 0 means all messages including thread messages.

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?

The description states a specific verb and resource: 'Get chat messages from a Talk conversation.' It goes beyond a vague label by describing the compact output format and reverse chronological order, making it clearly distinct from siblings like get_conversation, list_conversations, and get_thread.

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?

The description gives clear operational guidance: start with a small limit, paginate with before_message_id, use list_conversations to find tokens, and use list_threads for thread IDs. It does not explicitly contrast with alternative message-related tools like get_conversation or send_message, but the context for reading messages is strong.

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

Deploy Server