Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Viwoods MCP read the latest page from my Health notebook"
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.
Unofficial fan project. Not made by, affiliated with, or endorsed by Viwoods. If Viwoods themselves ever wants this taken down, just say so and it will be, no argument.
Viwoods MCP gives Claude a window onto your Viwoods AiPaper notebooks, and only the part of it you choose. It's an MCP server for Claude Desktop or Claude Code that reads the stock Paper app over adb and hides everything outside the folders you've allowed.
Share your Health folder, keep your Journals out of it:
viwoods-mcp allow Health
viwoods-mcp deny Journals
viwoods-mcp policy # what that shares, folder by folder🔒 A folder allow/deny list. One small file decides what Claude can see. Nothing is shared until you add a rule, deny always beats allow, and a notebook you haven't shared doesn't exist as far as Claude can tell.
🪶 No root. It reads the tablet with plain adb, through the Paper app's own content provider and its page files. If the provider says nothing it falls back to a database snapshot, and that part needs adb root.
👀 Claude can read your handwriting. Pages come back as images, so it reads the ink itself rather than a lossy OCR pass.
📜 An audit log. A private record of every notebook and page Claude was shown, what it searched for, and what it asked for that wasn't shared. viwoods-mcp audit shows the end of it. It never holds page images or text.
🔎 Optional handwriting search, if you also run paperd's ink index. Every hit comes with a precise reference (Journals › 2026-04-07 · p. 3 · changed 2026-04-07) and a count of how many matches there were in all.
🖼️ Show me where I wrote it. viwoods_show_match crops the page to the words you asked about, outlined and enlarged, using the word boxes in paperd's index. The crop is also saved on your PC and can be opened in your image viewer.
✍️ Optional PDF import, off by default: put a PDF on the tablet as a notebook to write on, into a folder you've shared.
Tool | What it does |
| The folders of shared notebooks with counts (with and without their subfolders), and how many notebooks are not shared (a number only) |
| Shared notebooks: id, title, folder, page count, which pages have writing (as ranges, |
| Pages of a shared notebook as images (up to 8 per call) |
| Words found in the handwriting of shared notebooks, newest page first, optionally limited by |
| A page zoomed in on where some words are written (up to 3 spots, outlined in red), saved to your PC. Needs paperd's index |
| A PDF from your PC as a new notebook. Off until |
Related MCP server: onenote-mcp
Install (Python 3.11 or newer, with adb on your PATH and USB debugging on the tablet):
git clone https://github.com/desyncc/viwoods-mcp.git
cd viwoods-mcp
uv venv && uv pip install -e .No uv? python -m venv .venv && .venv/bin/pip install -e . does the same.
Connect the tablet, over USB or over Wi-Fi with adb connect <tablet-ip>:5555.
Share something. Nothing is shared by default:
.venv/bin/viwoods-mcp allow Health
.venv/bin/viwoods-mcp deny JournalsCheck what that exposes:
.venv/bin/viwoods-mcp policyIt lists every top-level folder and how many of its notebooks would be shared.
Add it to Claude.
Claude Desktop, in claude_desktop_config.json:
{"mcpServers": {"viwoods": {"command": "/path/to/viwoods-mcp/.venv/bin/viwoods-mcp",
"args": ["--serial", "192.168.1.50:5555"]}}}Claude Code:
claude mcp add viwoods -- /path/to/viwoods-mcp/.venv/bin/viwoods-mcp--serial (or $VIWOODS_MCP_SERIAL) is only needed with more than one device, or for Wi-Fi adb.
Everything lives in one file, ~/.config/viwoods-mcp/policy.json (or wherever $VIWOODS_MCP_POLICY points):
{
"allow": ["Health", "Reference/Recipes"],
"deny": ["Health/Private"],
"write": false
}Key | Meaning |
| Folder paths Claude may see |
| Folder paths it may not. Deny always wins over allow |
| Lets |
How a rule matches:
A rule is a folder path, case-insensitive, ignoring spaces at the ends of a name. * is the only wildcard and matches within a name (Ref*); [, ] and ? are ordinary characters.
It covers that folder, every folder under it, and every notebook in them.
The last part can be a notebook's title, so Health/Meds shares just that one.
"*" allows everything. Pair it with deny rules for what you keep back.
A notebook that no rule allows is not shared, and with no file at all nothing is. The same goes for a file that can't be read, or whose deny isn't a list.
write is on only for a literal true; "true", 1 and the like leave it off.
Edits apply to the next call. There's nothing to restart.
Environment variable | |
| Path to the policy file |
| adb serial, or |
| Path to paperd's |
| Where the audit log goes (default |
|
|
| How wide a |
| Where those crops are saved (default |
viwoods_list_notebooks and viwoods_search_handwriting take since and until, so "what did I write this week" or "anxiety in September" doesn't mean reading everything. They go by when each page last changed (the notebook's time if the app gave none). A value is any of:
Value | Means |
| that whole day (as |
| that moment, in this PC's time zone unless it names an offset |
| those days |
| that long ago ( |
viwoods-mcp # run the server over stdio (what Claude launches)
viwoods-mcp allow Health # add an allow rule
viwoods-mcp deny Journals # add a deny rule
viwoods-mcp remove Journals # drop a rule from either list
viwoods-mcp policy # show the policy and what it shares
viwoods-mcp audit -n 30 # the last 30 things Claude was shown
viwoods-mcp write on # let viwoods_add_pdf_notebook put PDFs on the tablet
viwoods-mcp write offRules can be edited by hand in the policy file too.
The notebook tree comes from the Paper app's own content provider (FileInfoProvider), which the ordinary adb shell user can query. The pages are read from the app's folder under /sdcard/Android/data, which that user can read as well. That's why it needs no root.
If the provider answers nothing, it snapshots the app's Room database instead. That path needs adb root.
Hidden notebooks stay hidden. Encrypted, recycle-bin, deleted and PDF-template notebooks never reach the tools.
Not probe-able. Asking for a notebook that isn't shared gets the same "no shared notebook called…" answer as asking for one that was never there, in viwoods_read_pages and in search.
viwoods_add_pdf_notebook uses the app's own PDF import: the PDF is pushed to /sdcard/Documents/viwoods-mcp/ and has to stay there, because the app keeps its path rather than a copy.
viwoods_show_match finds the words in the word boxes paperd's index stores ([word, x0, y0, x1, y1], in the page image's own pixels), groups them into spots, and crops each with the lines it sits on, as far along as they are written (up to a width limit, so the enlargement stays readable). Whether the chat window displays the image depends on the Claude app, which is why it's also saved to disk and can be opened for you.
viwoods_search_handwriting reads the text paperd's ink index recognised from your pages (the ink_pages table in its index.db). Without that file it simply returns nothing.
Checked on an AiPaper (SE03) with firmware 3.15.x and Paper app 1.8.9. A different firmware may move things around; the provider authority and the page-file layout are the two places to look.
The read tools are marked read-only to clients, so an app can run them without asking each time and still stop to ask before viwoods_add_pdf_notebook. viwoods_show_match is marked as not read-only, because it saves a crop file on your PC.
Crops saved by viwoods_show_match are pieces of your pages kept in a folder only you can read; delete the folder whenever you like.
It doesn't rename, delete, tag or move notebooks (the app offers no safe route for any of that), and it never touches the notebook lock or the app's other controls. Reading a page sends that page's image to whichever Claude you connected, so what you allow is what it can see. Allow carefully.
While building this I found that the Paper app's FileInfoProvider is exported with no permission, and it exposes the notebook lock password plus two updates that clear every notebook's encrypted state and delete that password, to any app installed on the tablet. This project doesn't use any of that and never will. It's mentioned so you know the lock isn't a barrier against other apps on the device.
uv pip install -e ".[dev]"
.venv/bin/python -m pytestThe suite runs against fakes, so it needs neither a tablet nor adb.
MIT licensed.
Put a PDF from this PC on the Viwoods tablet as a new Paper notebook to write on, into a shared top
level folder (or the top level). Only when the user has switched writing on.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| folder | No | ||
| pdf_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations cannot express: the source is a local PC file and the operation requires the tablet's writing mode to be enabled. It omits failure behavior (folder missing, title collision), which keeps it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the action first, then destination, then precondition. The parenthetical '(or the top level)' and 'to write on' add mild redundancy but every clause carries real information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation here. For a 3-parameter write operation, the description covers source, destination, and the enabling precondition; only edge-case behavior (existing folder, duplicate titles, invalid path) is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all three parameters. It clarifies `folder` semantics (shared top-level, or top level when omitted, matching default "") and identifies `pdf_path` as a file from this PC, but says nothing about `title` beyond implying the notebook's name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource chain: put a PC PDF onto the Viwoods tablet as a new Paper notebook. The action is unmistakably distinct from siblings like viwoods_list_notebooks or viwoods_read_pages, so an agent can route to it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition ('Only when the user has switched writing on') that gates invocation, which is more than most definitions offer. It does not name alternatives or say what to do when the gate is not met, so it falls short of a full when/when-not/alternative statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The folders of shared notebooks in the Viwoods tablet's Paper app (not Nextcloud folders).
notebooks counts a folder and everything under it, directly_inside only its own; also
the shared notebooks at the top level, and how many notebooks are not shared (a count only).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: that `notebooks` is recursive while `directly_inside` is shallow, that top-level shared notebooks are also included, and that the unshared figure is a count only rather than a list. That is meaningful disclosure beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the tool returns, and every clause carries information (scope, recursion semantics, unshared count). The parenthetical Nextcloud disclaimer is slightly interruptive but earns its place as disambiguation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with full annotation coverage and an output schema, the description supplies the one thing structured data cannot: the meaning of the recursive vs shallow counts. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4. The description's discussion of `notebooks` and `directly_inside` describes return shape rather than inputs, and an output schema exists, so no additional parameter meaning is required or expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource (folders of shared notebooks) and scopes it precisely to the Viwoods tablet's Paper app, explicitly ruling out Nextcloud folders. The listing verb comes from the tool name, and the scope line distinguishes it from viwoods_list_notebooks. It is clear, though it leans toward describing output fields rather than restating the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to choose this tool over siblings such as viwoods_list_notebooks or viwoods_search_handwriting, and no preconditions or exclusions beyond the Nextcloud disambiguation. An agent must infer the use case from the resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shared notebooks in the Viwoods tablet's Paper app, newest first: id, title, folder, page
count, which pages have writing (e.g. "1-3, 5") and when anything in it last changed. folder limits
it to a folder and the folders under it. query keeps to notebooks whose title or folder holds
every word of it (e.g. "recipes"), with no need for the handwriting index. since / until keep to notebooks with writing
that changed in that time, and add pages_changed (which pages) to each; they take a date
(2026-10-01, whole day), a date and time, today, yesterday, or how long ago (7d, 2w, 12h, 3m).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| since | No | ||
| until | No | ||
| folder | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met elsewhere. The description adds genuinely behavioral facts: folder is recursive into subfolders, query matches every word against title or folder, and since/until alter the response by appending pages_changed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient; parameter behavior is front-loaded right after the resource statement and no sentence is filler. The leading enumeration of output fields is somewhat redundant given an output schema exists, slightly diluting the front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param, zero-required filter tool this covers everything needed: all four filters, their interaction with the response, ordering, and time-format grammar. Return fields need not be re-explained since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden and does: folder recursion, query's AND-word matching on title/folder, and since/until accepting a date, date+time, 'today', 'yesterday', or relative durations (7d, 2w, 12h, 3m) with whole-day semantics for bare dates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (shared notebooks in the Viwoods Paper app) plus ordering (newest first) and the returned shape. The clause 'with no need for the handwriting index' implicitly separates it from viwoods_search_handwriting, so an agent can route between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains what each filter selects and when the since/until pair changes the output (adds pages_changed), which is real usage context. It stops short of naming alternatives explicitly (e.g. 'use search_handwriting for page content'), leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pages of a shared Viwoods Paper notebook as images, to read the handwriting. notebook is
its title or id; pages are positions (1 = first), at most 8 per call. Pages with nothing
written are not sent; the first line says which.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | Yes | ||
| notebook | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real behavioral detail beyond them: a hard cap of 8 pages per call, the fact that blank pages are silently omitted, and that a first-line header reports which pages were skipped. It stops short of describing auth/sharing requirements or how the images are delivered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what is returned, then parameter semantics, then the omission behavior. Every sentence contributes distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain returns and largely does: images of the pages, blank pages withheld, header line identifying what was sent. It leaves minor gaps on how the images are delivered and any sharing/auth prerequisite implied by 'shared'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden and does so: `notebook` accepts a title or an id, and `pages` are 1-based positions with a maximum of 8 per call. Both required parameters are given meaning that the bare schema cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (read) and resource (pages of a shared Viwoods Paper notebook), and states the payload form ('as images, to read the handwriting'), which is what separates it from viwoods_list_notebooks or viwoods_search_handwriting. It does not explicitly name a sibling to route against, so it falls just short of the top mark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'to read the handwriting' implies the use case and implicitly contrasts with search_handwriting, but there is no explicit when-to-use, when-not, or named alternative. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find words in the handwriting of shared Viwoods Paper notebooks: the text paperd's index read
from the pages (it needs paperd's index file, VIWOODS_MCP_INDEX, and only covers pages it has
read). Returns newest page first, each hit with a reference (Folder › Title · p. N · changed
date), the page and a snippet, plus total_matches in all. since / until keep to pages that
changed in that time (a date, date and time, today, yesterday, or how long ago: 7d, 2w, 12h, 3m).
Cite the reference rather than retelling the page; to show the user the spot, use
viwoods_show_match.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| since | No | ||
| until | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, closed-world read, and the description adds genuinely new behavioral facts: dependence on paperd's index file, that coverage is limited to pages already read, newest-page-first ordering, and the shape of each hit (reference, page, snippet) plus total_matches. No contradiction with the readOnly/destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense paragraph, front-loaded with the purpose, with every clause carrying information (index dependency, ordering, date syntax, citation guidance, handoff). It is slightly run-on and could be broken into purpose/coverage/filters/next-step, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be re-explained, and the description still supplies the coverage limits, filter semantics, ordering, and the sibling handoff an agent needs to call this correctly. Nothing material is missing beyond the undocumented 'limit' default, which the schema already carries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load, and it does for three of four params: query (words in handwriting), and since/until with concrete accepted forms (date, date+time, today, yesterday, 7d/2w/12h/3m). Only 'limit' is left unexplained, a small gap given the otherwise strong compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — find words in the handwriting of Viwoods Paper notebooks — and immediately scopes it to what paperd's index actually read. It names the sibling it hands off to (viwoods_show_match), so an agent can separate it from viwoods_read_pages and viwoods_show_match without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating context (requires VIWOODS_MCP_INDEX and only covers pages paperd has indexed) and routes the 'show the user the spot' case to viwoods_show_match. It also instructs to cite the reference rather than retell the page. It stops short of an explicit when-not versus viwoods_read_pages, but the practical routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the user where something is written: the page of a shared notebook zoomed in on words
(outlined in red, up to 3 spots), also saved to a folder on their PC and, if they've turned it
on, opened there. Use it when they ask to see or be shown where they wrote something; take
notebook and page from viwoods_search_handwriting. Needs paperd's index for where words sit.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| words | Yes | ||
| notebook | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only say readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), the description discloses real side effects: writing a file to a folder on the PC, conditionally opening it there, the 3-match cap, and a dependency on paperd's index. It does not contradict readOnlyHint=false; it confirms a side-effecting operation. Gaps remain (which folder, overwrite behavior, failure modes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core behavior before the usage trigger and the input-sourcing note. Slightly dense and parenthetical, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains what the user sees (zoomed page with red outlines, saved file, optional open). It covers effects and dependencies well, though folder location and error conditions are left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 3 required params, so the description must carry the load, and it does: `words` is the text to outline (max 3 hits), while `notebook` and `page` are identifiers sourced from viwoods_search_handwriting. It does not clarify the expected format of `notebook` (name vs. id), leaving a minor ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb and resource (show the user a zoomed page with `words` outlined in red) plus precise scope details (up to 3 spots, saved to a PC folder). It is clearly distinguishable from siblings like viwoods_search_handwriting, which it positions as the finder rather than the displayer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the trigger ("Use it when they ask to *see* or be shown where they wrote something") and the prerequisite source for inputs (take `notebook` and `page` from viwoods_search_handwriting). It stops short of naming a when-not condition or an explicit alternative to this display action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0viwoods_add_pdf_notebookviwoods_list_foldersviwoods_list_notebooksviwoods_read_pagesviwoods_search_handwritingviwoods_show_matchScored across 6 tools
Each tool has a distinct verb+object and purpose: listing folders vs notebooks, reading page images, searching handwriting, showing a match, and importing a PDF. The descriptions clearly delineate boundaries, and no two tools appear to do the same thing.
All tools use the viwoods_ prefix followed by snake_case verb_noun phrasing, even for multiword objects like add_pdf_notebook. The pattern is predictable and consistent throughout.
Six tools cover the core workflows—listing folders and notebooks, reading pages, searching handwriting, showing matches, and importing PDFs—without redundancy. This is a well-scoped set for the server's purpose.
The surface covers read/list/search/show and one create operation (PDF import), but lacks update/delete/rename/move operations for notebooks and folders. These are minor gaps for a primarily read-oriented assistant, workable since users can manage such changes on the tablet.
Read and search your handwritten Boox notes from Claude or ChatGPT. Needs a Margen account.
Give Claude only the Google Drive files you choose. Every action logged.
Notes and actions in one app. Let Claude or ChatGPT read and update them.
Notes and memory assistant: one Markdown vault that Claude, ChatGPT and any MCP client can share.
