How do I use textview-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@textview-mcp Find my notes about the API redesign" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

textview-mcp

by mrliuzhiyu

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

textview-mcp

textview-mcp is an MCP server that connects AI assistants (Claude, Cursor, Windsurf, etc.) to TextView — a cloud-based note-taking platform designed for AI agents.

Think of it as persistent memory for your AI: meeting notes, research findings, code snippets, daily journals — anything your AI generates can be saved, searched, and retrieved across sessions.

Why?

AI conversations are ephemeral. You have a great brainstorming session with Claude, close the window, and it's gone. textview-mcp solves this:

AI writes, you review — Let your AI agent save documents directly. Review them later on textview.cn from any device.
Cross-session memory — Claude in one conversation can read what Claude in another conversation wrote.
Cross-tool sync — Save from Cursor, read from Claude Desktop, review on your phone.
Rich formatting — Documents are stored as rich text (HTML), not plain text.

Related MCP server: CyberMem

Quick Start

1. Get your API token

2. Configure your AI tool

Edit claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "textview": {
      "command": "npx",
      "args": ["-y", "textview-mcp"],
      "env": {
        "TEXTVIEW_TOKEN": "tv_your_token_here"
      }
    }
  }
}

Restart Claude Desktop after saving.

Create or edit .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "textview": {
      "command": "npx",
      "args": ["-y", "textview-mcp"],
      "env": {
        "TEXTVIEW_TOKEN": "tv_your_token_here"
      }
    }
  }
}

Go to Settings → MCP and add:

{
  "mcpServers": {
    "textview": {
      "command": "npx",
      "args": ["-y", "textview-mcp"],
      "env": {
        "TEXTVIEW_TOKEN": "tv_your_token_here"
      }
    }
  }
}

claude mcp add textview -- npx -y textview-mcp

Then set the environment variable TEXTVIEW_TOKEN=tv_your_token_here.

3. Start using it

Just ask your AI naturally:

"Save this conversation as a document called 'Meeting Notes March 11'"

"Show me my recent documents"

"Find my notes about the API redesign"

Tools

Tool	Description
`save_document`	Save a new document to TextView
`list_documents`	List documents (with optional search)
`get_document`	Retrieve a document by ID
`update_document`	Update an existing document's title or content

Use Cases

Daily Journal

"Save a journal entry for today: summarize what we discussed and the decisions we made."

Research Assistant

"Save this research summary about MCP protocols to my notes."

Code Documentation

"Document the architecture of this project and save it to TextView."

Meeting Notes

"We just finished our sprint planning. Save the action items as a document."

Cross-Session Context

"Check my notes — did we decide on PostgreSQL or MySQL last week?"

Requirements

Node.js 18+
A free TextView account

Environment Variables

Variable	Required	Description
`TEXTVIEW_TOKEN`	Yes	API token (starts with `tv_`), generated at textview.cn

How It Works

Your AI Tool (Claude, Cursor, etc.)
    ↕ MCP Protocol (stdio)
textview-mcp (this package)
    ↕ HTTPS
TextView Cloud API
    ↕
Your Documents (accessible from any device)

Development

git clone https://github.com/mrliuzhiyu/textview-mcp.git
cd textview-mcp
npm install
npm run dev

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

MIT

Available Tools

6 tools

get_documentC

获取单个文档的完整内容。

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	文档 UUID

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation via 获取 and hints that full content is returned, but it says nothing about required permissions, behavior when the document is missing, or the response shape. For a tool with zero annotation coverage this is a significant gap.

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?

A single short sentence with no filler, and the core purpose is front-loaded. It is efficient, though it borders on under-specification rather than being genuinely concise.

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 simple one-parameter read tool with no annotations and no output schema, the description conveys the essential purpose and that full content is returned. It omits error/not-found behavior and return format, which keeps it at minimum viable rather than complete.

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 description coverage is 100% — the single id parameter is documented in the schema as a document UUID with format uuid. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

The description states a specific verb (获取) and resource (单个文档的完整内容), making it clear this is a single-document content retrieval. It does not explicitly contrast itself with siblings like list_documents or update_document, though the word 单个 implies a single-item fetch rather than a listing.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as list_documents (for many) or update_document (for mutating). The agent must infer usage entirely from the tool name and the phrase 单个文档.

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

list_documentsB

列出 TextView 中的文档，按更新时间倒序排列。

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	返回数量，默认 20
`search`	No	按标题模糊搜索

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the burden but only discloses one behavioral trait: results are sorted by update time descending. It says nothing about pagination behavior, whether limit caps the total result set, or how to exhaustively retrieve all documents.

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?

A single short sentence with the resource and the ordering constraint front-loaded; nothing wasteful.

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 simple two-optional-parameter list tool with no output schema and no annotations, the description covers scope and ordering but omits pagination behavior and result-envelope details. Adequate but with a noticeable gap for an agent deciding how to page through documents.

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 description coverage is 100%, so both limit (default 20, max 100) and search (fuzzy title match) are already documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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?

States a specific verb (列出/list) and resource (文档/documents) with the source context (TextView) and ordering. Clearly distinguishable from the sibling list_memos by resource, though it does not explicitly name alternatives.

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

Usage Guidelines2/5

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

Provides no guidance on when to use this versus get_document or list_memos. The ordering statement hints at listing semantics but there are no conditions, prerequisites, or exclusions stated.

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

list_memosC

查询 TextView 记录区的碎片记录，按时间倒序。

ParametersJSON Schema

Name	Required	Description
`date`	No	按日期过滤，格式 YYYY-MM-DD
`limit`	No	返回数量，默认 20
`source`	No	按来源过滤: web / desktop / mcp / xiaozhi / cli / api

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It states the sorting order (time descending) but does not disclose whether this is a read-only operation (implied but not explicit), pagination behavior, permissions required, or error handling. The description only partially covers behavioral aspects.

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?

The description is a single concise sentence that front-loads the core purpose and sorting order. It is efficient but could be slightly more informative without being verbose.

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?

With no output schema and no annotations, the description should ideally provide more context about return values, pagination, and usage scenarios. It covers the basic purpose but leaves gaps for an agent to fully understand the tool's behavior and constraints.

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 description coverage is 100%, so the schema already documents all three parameters fully. The description adds no parameter-level details beyond the schema, which is acceptable given the high coverage.

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

Purpose3/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: querying fragment memos in a TextView record area, sorted by time descending. However, it does not clearly distinguish from the sibling 'save_memo', and the term 'TextView 记录区' is context-specific without explaining its relevance. The purpose is understandable but lacks sibling differentiation.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'list_documents' or 'save_memo'. It simply describes what it does without indicating appropriate contexts or exclusions.

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

save_documentA

保存新文档到 TextView。content 必须为 HTML 格式（不要用 Markdown）。例: 标题段落列表项

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	文档标题
`content`	No	HTML 格式内容。用 <h2> <p> <ul><li> <ol><li> <blockquote> <strong> <em> <code> 等标签。不要用 Markdown 语法。

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose a meaningful behavioral constraint — content must be HTML, not Markdown — which prevents malformed input. But it omits what happens on success, whether an existing title is overwritten, and any permission/return behavior for this write operation.

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?

A single front-loaded sentence states the action, followed by the critical format constraint and a concrete example. No filler; every element earns its place.

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 save tool with no annotations and no output schema, the description covers the input format well but is silent on the write's side effects (overwrite semantics, return value). Adequate but with clear gaps for a mutation operation.

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 description coverage is 100%, so both parameters are already documented in the schema. The description restates the HTML format for content but adds no syntax or validation detail beyond what the schema's own description provides. Baseline 3 is appropriate.

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?

States a specific verb+resource: '保存新文档到 TextView' (save a NEW document). The word '新' implicitly distinguishes it from the sibling update_document, but no alternative is named explicitly. An agent can grasp the core action 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 Guidelines3/5

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

The word '新' (new) implies this is for creating rather than updating, giving weak when-to-use guidance. However, no alternatives (update_document, save_memo) are named and no exclusions are stated. Usage is left largely to inference.

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

save_memoA

保存一条碎片记录到 TextView 记录区。适用于快速笔记、语音转文字、剪贴板内容等碎片化信息。

ParametersJSON Schema

Name	Required	Description
`source`	No	来源标识: mcp / xiaozhi / cli / api（默认 mcp）
`content`	Yes	记录内容（纯文本）
`source_name`	No	来源设备名称，如 "小智音箱"、"录音笔"

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It identifies the destination area (TextView 记录区) and the kind of content, but does not disclose mutation side effects, persistence semantics, permissions, return values, or whether saves append or overwrite.

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?

Two sentences: the first states the core action and destination, and the second supplies concise usage examples. It is front-loaded and contains no wasted text.

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 a low-complexity tool with three fully described parameters and no output schema, the description adequately covers purpose and usage. It does not add behavioral details for this mutation tool, but the rich schema carries the parameter burden.

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 100%, so the input schema already documents all three parameters, including the source enum-like values and default. The description adds no parameter meaning beyond the schema, making the baseline score of 3 appropriate.

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?

The description states a specific verb (保存/save) and resource (碎片记录/fragment record) directed at a named storage area (TextView 记录区). It distinguishes the tool from a general document save by emphasizing fragmented information, though it does not explicitly name or contrast with the sibling save_document.

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?

It gives clear usage scenarios: quick notes, speech-to-text, and clipboard content, which tells the agent when this tool is appropriate. It does not provide exclusions or explicitly name save_document as the alternative for non-fragmented content.

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

update_documentB

更新已有文档的标题或内容。至少提供 title 或 content 之一。content 必须为 HTML 格式（不要用 Markdown）。

ParametersJSON Schema

Name	Required	Description
`id`	Yes	文档 UUID
`title`	No	新标题
`content`	No	HTML 格式内容。用 <h2> <p> <ul><li> <blockquote> <strong> <em> 等标签，不要用 Markdown。

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It mentions the HTML-not-Markdown constraint but omits whether updates overwrite or merge, whether missing fields are preserved, permission requirements, or return 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 compact sentences, appropriately sized for the tool's simplicity. The purpose statement is front-loaded, and the constraints follow in logical order.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description leaves significant gaps: no overwrite/merge semantics, no permission or validation behavior, and no response contract. The HTML format hint is covered but insufficient for a write operation.

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 description coverage is 100%, so the schema already documents all three parameters, including that content must be HTML. The description reiterates the at-least-one-of-title-or-content constraint, which adds a small amount of semantic value but mostly duplicates structured fields.

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 and resource ('更新已有文档') and identifies the exact fields being modified (标题或内容). This distinguishes it from siblings save_document and get_document, which respectively create and retrieve.

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

Usage Guidelines3/5

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

Provides one constraint — at least one of title or content must be provided — which is genuinely useful usage guidance. However, it doesn't explain when to use update_document versus save_document (e.g., editing an existing doc vs. creating a new one).

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.1.0Sep 13, 2026
- First observedget_document
- First observedlist_documents
- First observedlist_memos
- First observedsave_document
- First observedsave_memo
- First observedupdate_document

Deploy Server

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

TDQS

B3.4/5.0

Scored 2026-09-13 09:20 across 6 tools

Disambiguation5/5

Tools are cleanly partitioned into document operations (save/list/get/update) and memo operations (save/list). save vs update is distinguished by creating a new document versus modifying an existing one, and document vs memo is distinguished by structured HTML documents versus fragmented notes. No overlapping purposes are apparent.

Naming Consistency5/5

All names use snake_case with a consistent verb_noun structure (save_, list_, get_, update_). The only minor variation is plural nouns for list operations versus singular for single-resource operations, which is conventional and readable.

Tool Count5/5

Six tools for a document and memo management server is well-scoped, with each operation serving a distinct purpose. The surface is not bloated or thin for the apparent scope.

Completeness3/5

Document lifecycle supports create, read, update, and list but has no delete operation, leaving a dead end for removing documents. Memos only support save and list, with no get/update/delete, so lifecycle coverage is notably incomplete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

ASR (에사) — Shared memory for AI toolsOAuth
com.asrmemory
Shared memory for AI tools — save notes and work records, recall them from any other tool.
1
TaprootOAuth
com.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Knowledge & Memory Note Taking
2
netcafe-memory A
com.ainetcafe
Cross-session, cross-device memory for your agent: remember and recall notes. No key to start.
Knowledge & Memory Note Taking
411
Tycana
io.github.tycana
Gives your AI assistant persistent memory and intelligence about your work patterns.
Knowledge & Memory Autonomous Agents Developer Tools
2

Related MCP Servers

Vector Memory MCP Server
Knowledge & Memory RAG Systems
NeerajG03
A
license
Not graded
quality
D
maintenance
Enables AI assistants to save and recall information from files or free-form notes using natural language, acting as a long-term memory system.
Updated 10 months ago (2025-11-05 11:31 UTC)
MIT
CyberMem
Knowledge & Memory
mikhailkogan17
F
license
Not graded
quality
C
maintenance
Enables AI tools like Claude and Cursor to share persistent memory across sessions.
Updated 7 months ago (2026-02-22 23:30 UTC)
5
-
simple-memory-mcp
Knowledge & Memory Search
chrisribe
A
license
Not graded
quality
C
maintenance
Provides AI assistants with persistent memory across sessions using local SQLite and keyword search, allowing storage and retrieval of user preferences, project context, and decisions.
Updated 5 months ago (2026-04-17 15:38 UTC)
11 npm
8
MIT
mor
Note Taking Knowledge & Memory
laat
A
license
Not graded
quality
A
maintenance
Enables AI assistants to search, read, create, update, and remove personal markdown notes stored locally, providing persistent memory across sessions.
Updated 6 days ago (2026-09-14 05:44 UTC)
60 npm
2
MIT