kakao-mcp

Overview Schema Source Related Servers Discussions Admin

kakao_read_messages

Read-only

Read KakaoTalk chat messages from a local database page by page, with date filters and pagination to retrieve oldest or newest messages without marking them as read.

Instructions

Read one chat's messages, a page at a time. Messages in a page are oldest first.

Does not open KakaoTalk or mark anything as read. Each message has a message_id, time (KST), sender ("me" for the user), type and text.

Paging:

No cursor: the newest page (or the oldest page with oldest_first=true).
Go back in time: pass before=; stop when older_cursor is null.
Go forward: pass after=; stop when newer_cursor is null.
since/until apply per call: pass them again on every page. Examples: whole chat from the start -> oldest_first=true, then follow newer_cursor. Everything since March -> since="2026-03-01", oldest_first=true.

Messages of type photo, photos (several photos), video, file, voice and emoticon carry an attachment summary; get the content (emoticons and photos as images) with kakao_get_attachment. A "reply" has reply_to (the quoted message's id and text). reactions lists reactions on a message: {"emoticon": name like "사랑" or "엄지척", "count", "mine"}, or for older messages {"reaction": heart|like|check|laugh|surprise|sad (best-effort name), "code", "count", "mine"}. Only counts and whether the user reacted are recorded, not who else did.

Input Schema

TableJSON Schema

Name	Required	Description
`after`	No	`newer_cursor` from a previous page: get the page after it.
`limit`	No	Messages per page. Default 100, max 1000 (larger values are capped).
`since`	No	Relative ("30m", "12h", "7d", "2w") or a KST date/time ("2026-03-01" or "2026-03-01 14:00"). A date-only `until` means the end of that day.
`until`	No	Relative ("30m", "12h", "7d", "2w") or a KST date/time ("2026-03-01" or "2026-03-01 14:00"). A date-only `until` means the end of that day.
`before`	No	`older_cursor` from a previous page: get the page before it.
`chat_id`	Yes	Chat id STRING from kakao_list_chats or kakao_search, passed back unchanged (ids exceed 2^53, so never convert them to numbers).
`oldest_first`	No	Start from the oldest message (within since/until) instead of the newest. Use to read a chat from the beginning.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that it does not open KakaoTalk or mark messages as read, explains the cursor state machine with stop conditions, clarifies that since/until apply per call, and reveals limits of reaction data ('not who else did'). This is substantial behavioral context the annotations alone do not provide.

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 block earns its place: purpose, side-effect disclosure, message fields, paging rules, examples, and attachment/reaction specifics. It is cleanly structured and front-loaded, so an agent can quickly understand the core operation before diving into pagination details.

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?

Given the tool's complexity (pagination, multiple cursor modes, time filters, varied message types), the description is remarkably complete. It covers what each page contains, how to traverse both directions, how to resume, how to filter, and what to do with attachments. The presence of an output schema means return-value format does not need to be spelled out here.

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?

Although the input schema already documents all 7 parameters at 100% coverage, the description adds critical semantic meaning: how cursors chain across pages, when to stop, what 'no cursor' means, and how oldest_first interacts with since/until. The worked examples make the parameter relationships actionable in a way the schema alone does not.

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 first sentence states a specific verb and resource: 'Read one chat's messages, a page at a time.' It immediately distinguishes this from listing chats, searching, or fetching attachments, and adds the page-ordering behavior ('oldest first') that defines the tool's scope.

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 paging section gives explicit instructions on when to pass before, after, since, until, and oldest_first, with concrete examples. It also routes attachment content retrieval to kakao_get_attachment. It does not explicitly list when to prefer kakao_search or kakao_list_chats, so it stops just short of full exclusion guidance.

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

Deploy Server