Skip to main content
Glama
mholzen

workflowy

by mholzen
OverviewSchemaRelated ServersScoreDiscussions
Go

Workflowy MCP Server & CLI

A feature-rich Model Context Protocol (MCP) server and Command Line Interface (CLI) for Workflowy written in Go. Connect your AI assistant (Claude, ChatGPT, etc.) to your Workflowy data or run commands from a terminal emulator or script, including search, bulk replace, usage reports, and offline access capabilities.

Go Homebrew MCP Compatible MIT License

Why This Workflowy MCP Server?

  • Full-text search with regex

  • Bulk search & replace

  • Content transformation (split, clean, pipe to LLMs)

  • Usage reports (stale nodes, size analysis, mirrors)

  • Sandboxed AI access with --write-root-id

  • Offline mode via backup files

  • CLI + MCP server in one tool

  • Caching for performance

  • Homebrew installation

  • Basic CRUD operations

  • Using short IDs (Copy Internal Link)

Related MCP server: WorkFlowy MCP Server

Quick Start

Install via Homebrew

brew install mholzen/workflowy/workflowy-cli

Configure Your API Key

mkdir -p ~/.workflowy
echo "your-api-key-here" > ~/.workflowy/api.key

Get your API key at https://workflowy.com/api-key/

Run Your First Command

# Get the top-level nodes, and nodes two levels deep
workflowy get

# Generate a report showing where most of your nodes are
workflowy report count | pbcopy   # paste directly into Workflowy!

Use pbcopy on macOS, clip on Windows, wl-copy on Linux, or xclip for X11 systems.

Use with Claude Desktop or Claude Code

Claude Code

claude mcp add --transport=stdio workflowy -- workflowy mcp --expose=all

Remove —expose=all to limit to read-only tools.

Claude Desktop

Add to your configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "workflowy": {
      "command": "workflowy",
      "args": ["mcp", "--expose=all"]
    }
  }
}

Restart Claude Desktop and start asking Claude to work with your Workflowy!

MCP Tools for AI Assistants

Read Tools (Safe)

Tool

Description

workflowy_get

Get a node and its descendants as a tree

workflowy_list

List descendants as a flat list

workflowy_search

Search nodes by text or regex

workflowy_targets

List shortcuts and system targets (inbox, etc.)

workflowy_id

Resolve short ID or target key to full UUID

workflowy_report_count

Find where most of your content lives

workflowy_report_children

Find nodes with many children

workflowy_report_created

Find oldest nodes

workflowy_report_modified

Find stale, unmodified nodes

workflowy_report_mirrors

Find most mirrored nodes (requires backup)

Write Tools

Tool

Description

workflowy_create

Create new nodes

workflowy_update

Update node content

workflowy_move

Move node to a new parent

workflowy_delete

Delete nodes

workflowy_complete

Mark nodes complete

workflowy_uncomplete

Mark nodes incomplete

workflowy_replace

Bulk find-and-replace with regex

workflowy_transform

Transform node content (split, trim, shell commands)

CLI Features

Search Your Entire Outline

# Find all TODOs (case-insensitive)
workflowy search -i "foobar"

# Regex search for dates
workflowy search -E "<time.*>"

# Search within a specific subtree (using Internal Link)
workflowy search "bug" --item-id https://workflowy.com/#/1bdae4aecf00

Bulk Search and Replace

# Preview changes first (dry run)
workflowy replace --dry-run "foo" "bar"

# Interactive confirmation
workflowy replace --interactive "foo" "bar"

# Use regex capture groups
workflowy replace "TASK-([0-9]+)" 'ISSUE-$1'

Some Common CRUD Operations

# Add a task to your inbox
workflowy create "Buy groceries" --parent-id=inbox

# Change the name of an item
workflowy update xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx --name "Project Plan v2"

# Move an item to a different parent
workflowy move <item-id> <new-parent-id>

# Mark a node as complete, using a short ID
workflowy complete https://workflowy.com/#/xxxxxxxxxxxx

# Resolve a short ID or target key to full UUID
workflowy id inbox

Transform Content

# Split a node's content by newlines into child nodes
workflowy transform <item-id> split -s "\n"

# Clean up text
workflowy transform <item-id> trim
workflowy transform <item-id> no-punctuation

# Pipe content through any shell command (e.g., an LLM)
workflowy transform <item-id> -x 'echo {} | llm "summarize this"'

Usage Reports

# Where is most of my content?
workflowy report count --threshold 0.01

# Which nodes have the most children?
workflowy report children --top-n 20

# Find stale content (oldest modified)
workflowy report modified --top-n 50

# Find most mirrored nodes (requires backup)
workflowy report mirrors --top-n 20

Data Access Methods

Choose the best method for your use case:

Method

Speed

Freshness

Offline

Best For

--method=get

Medium

Real-time

No

Specific items

--method=export

Fast*

1 min worst case (due to rate limiting)

No

Full tree access

--method=backup

Fastest

Stale

Yes

Bulk operations

*Cached after first fetch

Offline Mode with Dropbox Backup

Enable Workflowy's Dropbox backup and access your data offline:

workflowy get --method=backup
workflowy search -i "project" --method=backup

Installation Options

Homebrew (macOS & Linux)

brew install mholzen/workflowy/workflowy-cli

Scoop (Windows)

scoop bucket add workflowy https://github.com/mholzen/scoop-workflowy
scoop install workflowy

Go Install

go install github.com/mholzen/workflowy/cmd/workflowy@latest

Download Binary

Download pre-built binaries from GitHub Releases.

Docker

docker run --rm -e WORKFLOWY_API_KEY=your-key ghcr.io/mholzen/workflowy:latest get

From Source

git clone https://github.com/mholzen/workflowy.git
cd workflowy
go build ./cmd/workflowy

Documentation

Examples

AI Assistant Workflows

Ask Claude:

  • "Search my Workflowy for all items containing 'meeting notes'"

  • "Show me nodes I haven't touched in 6 months"

  • "Replace all 'v1' with 'v2' in my Project A folder"

  • "What's taking up the most space in my outline?"

  • "Which nodes are mirrored the most?"

  • "Move this item to my inbox"

CLI Workflows

# Morning review: find stale items
workflowy report modified --top-n 20

# Weekly cleanup: find oversized nodes
workflowy report count --threshold 0.05

# Find unnecessary mirrors
workflowy report mirrors --top-n 20

# Bulk rename: update project prefix
workflowy replace "OLD-" "NEW-" --parent-id projects-folder-id

# Split pasted content into child nodes
workflowy transform <item-id> split -s "\n"

Contributing

Contributions welcome! See the Contributing Guide.

# Development setup
git clone https://github.com/mholzen/workflowy.git
cd workflowy
go test ./...

License

MIT — see LICENSE

Acknowledgments

  • Thanks to Andrew Lisy for requesting a method to sandbox write commands

  • Thanks to Craig P. Motlin for pointing out mirrors are defined in the backup files

Available Tools

10 tools
workflowy_getC
Destructive

Get node and descendants

ParametersJSON Schema
NameRequiredDescriptionDefault
ancestor_depthNoInclude N levels of ancestors (-1 for all, 0 for none; requires export or backup method)
depthNoRecursion depth (-1 for all, default 2)
idNoID (default: root)None
include_ancestorsNoWrap result in ancestor path from root to target node (requires export or backup method)
include_empty_namesNoInclude items with empty names
methodNoAccess method: get, export, or backup (default: auto based on depth)
to_ancestorNoInclude ancestors up to and including this node ID (requires export or backup method)

TDQS

C2.6/5.0
Behavior1/5

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

Description says 'Get' (read-only), but annotations set destructiveHint=true, indicating a contradiction. No further behavioral details provided.

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

Conciseness3/5

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

Extremely concise at 4 words, but lacks necessary detail to fully inform an AI agent. It is front-loaded but under-specified.

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?

Given 7 parameters, many siblings, and no output schema, the description is incomplete. It relies entirely on schema descriptions, which may not capture all nuances.

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?

Input schema has 100% coverage with descriptions, so baseline is 3. Description adds no additional meaning beyond the schema.

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?

Description clearly states 'Get node and descendants', using a specific verb and resource. However, it does not differentiate from siblings like workflowy_list, which might also retrieve nodes.

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 vs alternatives. No exclusions or context provided.

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

workflowy_idA
Destructive

Resolve a short ID or target key to full UUID

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesID to resolve to full UUID

TDQS

A3.5/5.0
Behavior2/5

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

Annotations include destructiveHint=true and idempotentHint=false, but the description does not clarify potential side effects or state changes, and the wording 'resolve' suggests a read-only operation, contradicting the destructive hint.

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 a single sentence that is clear and to the point, with no unnecessary words.

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 tool with one parameter and no output schema, the description covers the basic purpose, but lacks behavioral context and usage guidance, leaving gaps in completeness.

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?

The description does not add meaning beyond the input schema; the parameter description in the schema already states 'ID to resolve to full UUID', matching the tool description.

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 clearly states the verb 'resolve' and the resource 'short ID or target key' to 'full UUID', distinguishing it from siblings like 'workflowy_get' which retrieves data.

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 description implies usage when needing to convert a short identifier to a UUID, but does not explicitly contrast with alternatives or provide conditions for when to use this tool over sibling tools.

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

workflowy_listC
Destructive

List descendants as flat list

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNoRecursion depth (-1 for all, default 2)
idNoID (default: root)None
include_empty_namesNoInclude items with empty names
methodNoAccess method: get, export, or backup (default: auto based on depth)

TDQS

C2.6/5.0
Behavior1/5

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

The description states 'list', implying a read-only operation, but annotations include destructiveHint=true, indicating potential side effects. This contradiction undermines transparency. Additionally, no behavioral details beyond the brief description are provided, despite the tool having significant behavior (e.g., recursion, flat output format).

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

Conciseness3/5

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

The description is extremely brief (5 words), which is concise but lacks structure. It does not front-load key details or organize information; it merely states the core purpose. While not verbose, it under-delivers for a tool with multiple parameters and a contradictory annotation.

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?

Given the tool has 4 parameters, destructiveHint=true, and no output schema, the description is incomplete. It does not explain the output format (flat list), the effect of the 'method' parameter, or the implications of destructiveHint=true. The absence of output schema is not compensated by description.

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?

The input schema has 100% coverage with descriptions for all four parameters, so the schema already provides meaning. The description adds only the concept of 'flat list' but no further parameter-specific semantics. Baseline score of 3 is appropriate as the description does not diminish or enhance understanding beyond the schema.

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 'List descendants as flat list' clearly states the action (list) and resource (descendants), and implies a flat output format, distinguishing it from siblings like workflowy_report_children which lists only direct children. However, it does not mention that it operates from a specific ID (default root), which is a minor gap.

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 is provided on when to use this tool versus alternatives such as workflowy_report_children or workflowy_get. The description lacks any context about prerequisites or exclusions, leaving the agent to infer usage from tool names alone.

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

workflowy_report_childrenC
Destructive

Rank nodes by immediate children count

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoID (default: root)None
methodNoAccess method: get, export, or backup (default: export)
preserve_tagsNoPreserve HTML tags in output
top_nNoNumber of top results to include (0 for all)

TDQS

C2.9/5.0
Behavior1/5

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

Annotations indicate destructiveHint=true, but the description says 'Rank nodes', implying a read-only operation. This contradiction is misleading and fails to disclose the destructive nature. The description does not add meaningful context beyond annotations.

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 purpose. It is not overly verbose, but there is room to add structure without losing conciseness.

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?

With annotations suggesting destructiveness and no output schema, the description should explain side effects, return values, and how parameters like top_n affect output. It is insufficiently 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%, so the description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.

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 clearly states the action (Rank) and the resource (nodes by immediate children count), distinguishing it from sibling tools like workflowy_report_count or workflowy_report_created.

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?

The description provides no guidance on when to use this tool versus alternatives such as workflowy_list or workflowy_search, and no exclusions or prerequisites are mentioned.

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

workflowy_report_countC
Destructive

Generate descendant count report

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoID (default: root)None
methodNoAccess method: get, export, or backup (default: export)
preserve_tagsNoPreserve HTML tags in output
thresholdNoMinimum ratio threshold (0.0 to 1.0)

TDQS

C2.9/5.0
Behavior2/5

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

Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond these. It does not explain what 'generate' entails (e.g., does it modify data?), nor does it clarify side effects or requirements, leaving the agent uninformed.

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 very concise—one sentence with no redundancy. It is front-loaded with the key action. However, it could benefit from structured details without becoming verbose.

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?

The tool has 4 parameters, no output schema, and is a report generator, yet the description provides no information about what the report contains, how to interpret results, or any limitations. Given the complexity, the description is insufficiently 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%, so baseline is 3. The description 'Generate descendant count report' adds no meaning beyond the schema's parameter descriptions, which already define each parameter sufficiently.

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 'Generate descendant count report' clearly indicates the verb (generate) and the specific resource (descendant count report). However, it does not differentiate from sibling tools like 'workflowy_report_children' which might have overlapping functionality, leaving ambiguity.

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 is provided on when to use this tool versus alternatives such as 'workflowy_report_children' or other reports. There are no prerequisites or contextual hints for using this tool appropriately.

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

workflowy_report_createdB
Destructive

Rank nodes by creation date (oldest first)

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoID (default: root)None
methodNoAccess method: get, export, or backup (default: export)
preserve_tagsNoPreserve HTML tags in output
top_nNoNumber of top results to include (0 for all)

TDQS

B3.1/5.0
Behavior1/5

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

Annotation destructiveHint=true contradicts the description of a read-only ranking operation. The description does not disclose destructive behavior or other side effects. Annotation contradiction present.

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 concise sentence, but it could benefit from slightly more detail without becoming verbose.

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?

The description is too brief given the tool's 4 parameters and lack of output schema. It does not explain return format, the meaning of parameters in context, or address the contradiction with annotations.

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 schema already documents parameters. The description adds no additional meaning beyond what parameters are, missing details on how 'method' or 'preserve_tags' affect the ranking.

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 clearly states the action (rank nodes) and the ordering (by creation date, oldest first). It distinguishes from sibling tools like workflowy_report_modified which ranks by modification date.

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 description implies use when wanting oldest nodes first, but provides no explicit guidance on when not to use or how it compares to siblings like workflowy_report_modified or workflowy_report_children.

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

workflowy_report_mirrorsA
Destructive

Rank nodes by mirror count (most mirrored first). Uses backup file as mirror data is only available there.

ParametersJSON Schema
NameRequiredDescriptionDefault
preserve_tagsNoPreserve HTML tags in output
top_nNoNumber of top results to include (0 for all)

TDQS

A4/5.0
Behavior3/5

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

Annotations already indicate destructiveHint=true, so the description is not required to repeat that. It adds value by explaining the backup file dependency, but does not elaborate on the nature of potential destructive actions, which is acceptable given the annotation coverage.

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 a single sentence that front-loads the core action and efficiently provides the key constraint. No unnecessary words or details.

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?

Given the tool's simplicity and the presence of annotations, the description covers the essential context: purpose and data source. It does not include return format details, but the schema sufficiently documents parameters, and the lack of output schema is acceptable for a report tool.

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 baseline is 3. The description does not add any additional information about the parameters beyond what is already in the schema, so it neither improves nor detracts.

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 clearly states the tool ranks nodes by mirror count, which is a specific and distinct action. It also explains the data source limitation, making the purpose unambiguous even without explicit 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 Guidelines4/5

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

The description provides clear context by stating it uses a backup file, implying when this tool is applicable. However, it does not explicitly mention when not to use it or list alternative tools, so it stops at clear context without exclusions.

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

workflowy_report_modifiedB
Destructive

Rank nodes by modification date (oldest first)

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoID (default: root)None
methodNoAccess method: get, export, or backup (default: export)
preserve_tagsNoPreserve HTML tags in output
top_nNoNumber of top results to include (0 for all)

TDQS

B3.2/5.0
Behavior2/5

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

The description implies a read-only ranking operation, but annotations set destructiveHint: true, creating a contradiction. No behavioral traits beyond basic ranking are disclosed, leaving the destructive nature unexplained.

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 a single, short sentence that conveys the core functionality without any unnecessary words.

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?

With 4 parameters and no output schema, the description is too minimal. It does not explain how parameters affect results, return format, or ranking behavior, leaving significant gaps for an agent.

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 description adds no new parameter meaning. The description does not elaborate on parameters beyond what the schema provides, earning a baseline score of 3.

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 clearly states the tool ranks nodes by modification date, oldest first. This distinguishes it from siblings like workflowy_report_created (by creation date) and workflowy_report_children.

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?

The description provides no guidance on when to use this tool over alternatives. Siblings include other report tools, but no criteria for selection are given.

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

workflowy_targetsC
Destructive

List available Workflowy targets (shortcuts and system targets)

ParametersJSON Schema
NameRequiredDescriptionDefault
methodNoAccess method for resolving root names: get, export, or backup

TDQS

C2.9/5.0
Behavior1/5

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

The description claims a read-only operation ('list'), but annotations set destructiveHint=true and readOnlyHint=false, creating a contradiction. No additional behavioral context is provided.

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 sentence, front-loaded and efficient, but it could be slightly more informative without sacrificing conciseness.

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?

No output schema exists, so the description should explain what is returned (e.g., a list of target names). It only mentions 'list' but not the format or details, and the annotation contradiction adds confusion.

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?

The schema covers the single parameter with a description. The description adds no extra meaning beyond what the schema already provides.

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 clearly states 'list available Workflowy targets (shortcuts and system targets)', which is a specific verb+resource that distinguishes it from sibling tools like workflowy_get or workflowy_search.

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. It does not mention prerequisites, exclusions, or that it should be called before other tools that need target identifiers.

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. Dates show when Glama detected each change.

  1. 10 tool updatesv0.4.1
    • Changedworkflowy_get6 fields changed
      • addedInput schema / properties / ancestor_depth
        Added value: +{
+  "default": 0,
+  "description": "Include N levels of ancestors (-1 for all, 0 for none; requires export or backup method)",
+  "type": "number"
+}
      • addedInput schema / properties / id
        Added value: +{
+  "default": "None",
+  "description": "ID (default: root)",
+  "type": "string"
+}
      • addedInput schema / properties / include_ancestors
        Added value: +{
+  "default": false,
+  "description": "Wrap result in ancestor path from root to target node (requires export or backup method)",
+  "type": "boolean"
+}
      • removedInput schema / properties / item_id
        Removed value: -{
-  "default": "None",
-  "description": "Workflowy item ID (None for root)",
-  "type": "string"
-}
      • addedInput schema / properties / method
        Added value: +{
+  "description": "Access method: get, export, or backup (default: auto based on depth)",
+  "type": "string"
+}
      • addedInput schema / properties / to_ancestor
        Added value: +{
+  "description": "Include ancestors up to and including this node ID (requires export or backup method)",
+  "type": "string"
+}
    • Addedworkflowy_id
    • Changedworkflowy_list3 fields changed
      • addedInput schema / properties / id
        Added value: +{
+  "default": "None",
+  "description": "ID (default: root)",
+  "type": "string"
+}
      • removedInput schema / properties / item_id
        Removed value: -{
-  "default": "None",
-  "description": "Workflowy item ID (None for root)",
-  "type": "string"
-}
      • addedInput schema / properties / method
        Added value: +{
+  "description": "Access method: get, export, or backup (default: auto based on depth)",
+  "type": "string"
+}
    • Changedworkflowy_report_children3 fields changed
      • addedInput schema / properties / id
        Added value: +{
+  "default": "None",
+  "description": "ID (default: root)",
+  "type": "string"
+}
      • removedInput schema / properties / item_id
        Removed value: -{
-  "default": "None",
-  "description": "Workflowy item ID (None for root)",
-  "type": "string"
-}
      • addedInput schema / properties / method
        Added value: +{
+  "description": "Access method: get, export, or backup (default: export)",
+  "type": "string"
+}
    • Changedworkflowy_report_count3 fields changed
      • addedInput schema / properties / id
        Added value: +{
+  "default": "None",
+  "description": "ID (default: root)",
+  "type": "string"
+}
      • removedInput schema / properties / item_id
        Removed value: -{
-  "default": "None",
-  "description": "Workflowy item ID (None for root)",
-  "type": "string"
-}
      • addedInput schema / properties / method
        Added value: +{
+  "description": "Access method: get, export, or backup (default: export)",
+  "type": "string"
+}
    • Changedworkflowy_report_created3 fields changed
      • addedInput schema / properties / id
        Added value: +{
+  "default": "None",
+  "description": "ID (default: root)",
+  "type": "string"
+}
      • removedInput schema / properties / item_id
        Removed value: -{
-  "default": "None",
-  "description": "Workflowy item ID (None for root)",
-  "type": "string"
-}
      • addedInput schema / properties / method
        Added value: +{
+  "description": "Access method: get, export, or backup (default: export)",
+  "type": "string"
+}
    • Addedworkflowy_report_mirrors
    • Changedworkflowy_report_modified3 fields changed
      • addedInput schema / properties / id
        Added value: +{
+  "default": "None",
+  "description": "ID (default: root)",
+  "type": "string"
+}
      • removedInput schema / properties / item_id
        Removed value: -{
-  "default": "None",
-  "description": "Workflowy item ID (None for root)",
-  "type": "string"
-}
      • addedInput schema / properties / method
        Added value: +{
+  "description": "Access method: get, export, or backup (default: export)",
+  "type": "string"
+}
    • Changedworkflowy_search7 fields changed
      • addedInput schema / properties / group_by
        Added value: +{
+  "description": "Group results by: parent, path, tree, modified.<unit>, created.<unit> (unit: year, month, day, or Go time format)",
+  "type": "string"
+}
      • addedInput schema / properties / id
        Added value: +{
+  "default": "None",
+  "description": "ID to search within (default: root)",
+  "type": "string"
+}
      • addedInput schema / properties / include_completed
        Added value: +{
+  "default": false,
+  "description": "Include completed nodes in search results (excluded by default)",
+  "type": "boolean"
+}
      • removedInput schema / properties / item_id
        Removed value: -{
-  "default": "None",
-  "description": "Limit search to this subtree (None for root)",
-  "type": "string"
-}
      • addedInput schema / properties / method
        Added value: +{
+  "description": "Access method: get, export, or backup (default: export)",
+  "type": "string"
+}
      • addedInput schema / properties / order_by
        Added value: +{
+  "description": "Sort results by: match, parent, path, modified, created (prefix +/- for asc/desc)",
+  "type": "string"
+}
      • addedInput schema / properties / path_max_length
        Added value: +{
+  "description": "Max characters per path segment name when using group_by=path",
+  "type": "number"
+}
    • Changedworkflowy_targets1 field changed
      • addedInput schema / properties
        Added value: +{
+  "method": {
+    "description": "Access method for resolving root names: get, export, or backup",
+    "type": "string"
+  }
+}
  2. 6 tool updatesv1.0.0
    • Removedworkflowy_complete
    • Removedworkflowy_create
    • Removedworkflowy_delete
    • Removedworkflowy_replace
    • Removedworkflowy_uncomplete
    • Removedworkflowy_update
  3. 6 tool updates
    • Addedworkflowy_complete
    • Addedworkflowy_create
    • Addedworkflowy_delete
    • Addedworkflowy_replace
    • Addedworkflowy_uncomplete
    • Addedworkflowy_update
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool targets a distinct operation: retrieval (get, list, search), resolution (id), reporting (various report_*), and listing targets. No two tools overlap in function; descriptions clearly differentiate them.

Naming Consistency5/5

All tools follow a consistent 'workflowy_<verb>_<noun>' pattern with verbs like get, id, list, report_*, search, targets. The report tools share a uniform prefix. No mixing of conventions.

Tool Count4/5

10 tools is a reasonable count for a read-only Workflowy server. It covers querying, searching, reporting, and identifier resolution without being excessive. Could be moderately expanded but is well-scoped.

Completeness3/5

The tool surface covers reading, searching, and reporting comprehensively, but lacks any write operations (create, update, delete) that are typical for a workflowy integration. This omission creates a notable gap for tasks requiring modification.

Maintenance

ActivityInactive
ResponsivenessWithin a week

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mholzen/workflowy'

If you have feedback or need assistance with the MCP directory API, please join our Discord server