The Logseq MCP Server enables programmatic interaction with Logseq graphs for knowledge management and organizational tasks.
Key capabilities include:
Page management: Create new pages (including journal pages) with custom properties, formats, and optional initial blocks
Block operations: Create, insert, edit, and manage blocks with custom UUIDs and positioning control
Content retrieval: Fetch page details, hierarchical block structures, and currently edited content
Navigation control: Enter/exit block editing mode with cursor position control
Graph exploration: List all pages in the graph, optionally filtering by repository
Active content access: Get information about the currently active page or block
This server serves as an API gateway for LLMs to directly interact with Logseq's knowledge base system.
Provides direct integration with Logseq's knowledge base, enabling interaction with Logseq graphs, creating pages, managing blocks, and organizing information programmatically.
Supports Markdown as a page format option when creating new pages in Logseq.
Supports Org format as a page format option when creating new pages in Logseq.
Click on "Install 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., "@Logseq MCP Server create a new page called 'Weekly Goals' with a task to review project documentation"
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.
Turn your Logseq graph into memory and workspace for AI agents. A
Model Context Protocol server for
Logseq with safety-scoped writes, an audit trail in your
daily journal, and verified queries exposed as tools. Built on FastMCP (the
high-level API of the official mcp package).
Targets the file/Markdown ("OG") version of Logseq — and plain-text files are part of why a graph makes good agent memory: git-syncable, greppable, durable, no lock-in. The newer DB (SQLite) version changed the underlying schema; some methods may behave differently there.
Agents need durable memory, and you already maintain one — your graph. The missing piece is access you can trust: an agent should read broadly and write usefully, but never touch what it shouldn't — and never do anything you can't see. Three design choices make that possible:
Namespace-scoped writes. Agents write only under their own prefix
(byAgent/ by default), plus one deliberately narrow cross-namespace channel
that can change nothing but a task's TODO/DOING/DONE marker. Blacklisted
pages are hidden and redacted from every read.
An audit trail in your daily journal. Every successful write appends a
line like 22:30 [[byAgent]] wrote [[byAgent/readingList/...]] to today's
journal — reviewing your agents' work becomes part of a morning routine you
already have.
Verified queries as tools. Ship known-good Datalog from config as named
tools (query_week_plan, …), so agents don't compose datascript by hand and
cheaper models stay reliable.
Related MCP server: Logseq MCP Tools
I run a small fleet of Claude Code agents with this server on an always-on Mac mini, against my live personal graph:
Nightly research. A link dropped into the reading list from the phone; at
night an agent claims it (status:: researching), reads the article — or
shallow-clones and reads the repo — writes a structured summary onto the page
and flips it to read.
Morning brief. At 08:30 a small model assembles a one-page dashboard — what was read overnight, week-plan progress, current NOW/DOING tasks — and sends a single push notification.
One journal for everyone. The human's tasks and the agents' audit lines interleave in the same daily note:
The pages the researcher writes — properties, summary, relevance — link straight into the rest of the graph:
flowchart LR
A[AI agents] -- MCP tools --> S[logseq-mcp]
S -- HTTP API --> L[Logseq graph]
S -. audit line per write .-> J[daily journal]
Y((you)) --> L
Y -- morning review --> JA running Logseq with the local HTTP API server enabled (Settings → Features → HTTP APIs server, then start it from the 🔌 menu).
An authorization token created in the HTTP API server settings.
Local (stdio), token from the environment:
claude mcp add logseq --scope user --env LOGSEQ_API_TOKEN=<YOUR_TOKEN> -- uvx mcp-server-logseqOr point it at a remote instance over Streamable HTTP (how phone and remote sessions reach a headless host — see Transports):
claude mcp add logseq --scope user --transport http http://<host>:8000/mcp \
--header "Authorization: Bearer <LOGSEQ_MCP_HTTP_TOKEN>"{
"mcpServers": {
"logseq": {
"command": "uvx",
"args": ["mcp-server-logseq"],
"env": {
"LOGSEQ_API_TOKEN": "<YOUR_TOKEN>",
"LOGSEQ_API_URL": "http://127.0.0.1:12315"
}
}
}
}Source | Token | URL |
Environment |
|
|
CLI flag |
|
|
The token is read from the environment or --api-key; it is never stored in
code. A .env file is supported (see .env.example).
Behaviour beyond the defaults is set in a TOML file — path from
LOGSEQ_MCP_CONFIG (default ~/.config/logseq-mcp/config.toml). Custom queries
live in EDN files next to it. The server runs fine with no config file (safe
read-mostly defaults); see examples/config.toml for a
full annotated example.
Section | Key options |
|
|
|
|
|
|
|
|
|
|
|
|
| a named query: |
Secrets and the API URL stay in the environment, never in this file.
By default the server runs over stdio (for Claude Desktop and other local clients). A Streamable HTTP transport is also available for remote/networked use (e.g. a phone client):
LOGSEQ_MCP_HTTP_TOKEN=<client-secret> \
mcp-server-logseq --transport streamable-http --host 0.0.0.0 --port 8000
# MCP endpoint: http://<host>:8000/mcpEnv vars: LOGSEQ_MCP_TRANSPORT, LOGSEQ_MCP_HOST, LOGSEQ_MCP_PORT,
LOGSEQ_MCP_HTTP_TOKEN (or --http-token).
The Streamable HTTP transport requires a bearer token: every request must
send Authorization: Bearer <LOGSEQ_MCP_HTTP_TOKEN>, or it gets 401. The
server refuses to start in this mode without a token set. Note this is a
distinct secret from LOGSEQ_API_TOKEN:
Secret | Direction |
| this server → Logseq |
| client (phone) → this server |
⚠️ A bearer token over plain HTTP is only safe on an already-encrypted channel. Don't expose the raw port to the open internet. The easy path for a home/headless host is Tailscale: install it on the host and the client, and reach
http://<host>.<tailnet>.ts.net:8000/mcpover the encrypted tunnel — no domains, nginx, or certificates. (tailscale servecan add TLS if you wanthttps://.)
Build once:
docker build -t logseq-mcp .Quick try (ephemeral — --rm removes the container on stop):
docker run --rm -p 8000:8000 \
-e LOGSEQ_API_TOKEN=<logseq-token> \
-e LOGSEQ_MCP_HTTP_TOKEN=<client-secret> \
-e TZ=Europe/Moscow \
logseq-mcpPersistent deploy (e.g. a headless Mac mini) — run once; --restart brings it
back after reboots:
docker run -d --name logseq-mcp --restart unless-stopped -p 8000:8000 \
-e LOGSEQ_API_TOKEN=<logseq-token> \
-e LOGSEQ_MCP_HTTP_TOKEN=<client-secret> \
-e TZ=Europe/Moscow \
-e LOGSEQ_MCP_CONFIG=/cfg/config.toml \
-v /path/to/config-dir:/cfg:ro \
-v "/path/to/your/graph:/graph:ro" \
logseq-mcp-v .../config-dir:/cfg — folder holding your config.toml (+ queries/,
rules/); set files_path = "/graph" in it to enable file search. Omit both
the mount and LOGSEQ_MCP_CONFIG to run on defaults.
-v .../graph:/graph — your Logseq graph folder (read-only), for file search.
-e TZ=<zone> — local time for audit-log timestamps (image bundles tzdata;
the clock is UTC otherwise).
The container serves Streamable HTTP on port 8000 and talks to a Logseq running
on the host. On Docker Desktop (macOS/Windows) the default
LOGSEQ_API_URL=http://host.docker.internal:12315 already points at the host;
on Linux add --add-host=host.docker.internal:host-gateway (or set
LOGSEQ_API_URL to the host IP). Make sure Logseq's HTTP API server is running
and listening.
All read output is normalized to a flat JSON shape and passed through the
blacklist. Reads resolve ((block refs)) non-lossily (the resolved block's
uuid/status is kept so you can act on it).
search — full-text search over block content (query, regex?, limit?,
case_sensitive?, exclude_journals?). Uses ripgrep over files_path when
set, else a datascript content match.
find_tasks — task blocks by markers?, tag?, under_tag? (descendant),
page?, priority?, limit?.
list_pages — page names under a namespace prefix? (depth? limits levels).
Discovers a namespace's child pages, which are separate pages a parent's
read_page won't show. Structure only, not block content.
custom_query — run a named query from the config (name, inputs?).
list_custom_queries — list the configured queries.
datascript_query — run a raw Datalog query (query, inputs?, rules?).
get_logseq_guide — returns the authoritative guide for querying/writing this graph (verified Datalog gotchas: lowercase names, prefix descendants, marker and journal-day types, tags vs refs, read/write scoping). A single source of truth co-located with the server, so agents don't re-derive (and mis-derive) behaviour.
read_page — a page as a normalized block tree (page, depth?).
read_block — a block and its children (uuid, depth?).
write_note — create/append/replace a page under agent_write_prefix
(subpath, content?, mode?, properties?).
set_page_properties — set/remove page properties (subpath, properties;
a null value removes one).
edit_block — replace one block's content (uuid, old_content,
new_content). Read-before-write is enforced: the edit is rejected unless
old_content matches the block's exact current content. Agent namespace only.
create_task — create a task block in the agent namespace (title, agent,
project?, marker?, priority?, tags?, plan_page?, blocks_on?,
on_page?). The only way to create tasks — write_note rejects content that
starts with a task marker.
set_task_status — change only a task's marker (uuid, status); gated by
[tasks].allow_status_change.
query_<name> — each config query with register_as_tool = true is
exposed as its own tool.
git clone https://github.com/dailydaniel/logseq-mcp.git
cd logseq-mcp
cp .env.example .env # fill in LOGSEQ_API_TOKEN
uv sync
uv run mcp-server-logseqInspect with the MCP Inspector:
npx @modelcontextprotocol/inspector uv --directory . run mcp-server-logseqMIT
Create a new page in Logseq with optional properties. Features: - Journal page creation with date formatting - Custom page properties (tags, status, etc.) - Format selection (Markdown/Org-mode) - Automatic first block creation Perfect for template-based page creation and knowledge management.
| Name | Required | Description | Default |
|---|---|---|---|
| create_first_block | No | Create initial block | |
| format | No | Page format | markdown |
| journal | No | Journal page flag | |
| page_name | Yes | Name of the page to create | |
| properties | No | Page properties |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions features like journal page creation, custom properties, format selection, and automatic first block creation, which adds useful context beyond basic functionality. However, it doesn't cover critical aspects like error conditions, permission requirements, or what happens on duplicate page names.
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?
The description is well-structured with a clear opening sentence followed by bullet points highlighting key features. It's appropriately sized and front-loaded with the main purpose. The bullet points could be slightly more concise, but overall it's efficient with minimal waste.
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 creation tool with 5 parameters, no annotations, and no output schema, the description provides adequate coverage of what the tool does and some behavioral context. However, it lacks information about return values, error handling, and more detailed usage scenarios that would be helpful given the tool's complexity and mutation nature.
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 100%, so the schema already documents all parameters thoroughly. The description adds some semantic context by mentioning 'journal page creation with date formatting' (relating to the journal parameter) and 'custom page properties (tags, status, etc.)' (relating to properties parameter), but doesn't provide additional syntax or format details beyond what the schema provides.
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 clearly states the tool creates a new page in Logseq with optional properties, which is a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like logseq_insert_block or logseq_get_all_pages, which handle different operations.
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?
The description mentions 'Perfect for template-based page creation and knowledge management,' which implies usage context but doesn't provide explicit guidance on when to use this tool versus alternatives like logseq_edit_block or logseq_insert_block. No when-not-to-use scenarios 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.
Enter editing mode for a specific block
| Name | Required | Description | Default |
|---|---|---|---|
| pos | No | Cursor position in block content | |
| src_block | Yes | Block UUID or reference |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('enter editing mode') but lacks behavioral details such as what 'editing mode' entails (e.g., UI changes, permissions required, or effects on other operations), rate limits, or error handling, making it insufficient for a mutation tool.
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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.
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?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't cover behavioral aspects, usage context, or what happens after entering editing mode, leaving significant gaps for an AI agent to understand and invoke it correctly.
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 100%, with clear documentation for both parameters (src_block and pos). The description adds no additional meaning beyond the schema, such as explaining how 'src_block' references work or when to use 'pos'. Baseline 3 is appropriate since the schema does the heavy lifting.
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 clearly states the verb ('enter editing mode') and resource ('for a specific block'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'logseq_insert_block' or 'logseq_get_editing_block_content', which also involve block editing or content retrieval, so it doesn't reach the highest clarity level.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid block reference), exclusions, or compare to siblings like 'logseq_exit_editing_mode' or 'logseq_insert_block', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exit current editing mode
| Name | Required | Description | Default |
|---|---|---|---|
| select_block | No | Keep block selected after exiting edit mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Exit current editing mode' implies a state change but doesn't disclose behavioral traits like whether this requires specific permissions, what happens to unsaved changes, or if it's reversible. For a state-changing tool with zero annotation coverage, this is inadequate.
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?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool and front-loaded with the core action.
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?
Given the tool's complexity (state-changing operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'exiting editing mode' means in practice, potential side effects, or return values, leaving significant gaps for an agent to understand the tool's behavior.
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 100%, with the single parameter 'select_block' fully documented in the schema. The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
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 'Exit current editing mode' clearly states the action (exit) and target (editing mode), but it's somewhat vague about what 'editing mode' entails in Logseq context and doesn't differentiate from sibling tools like logseq_edit_block or logseq_insert_block that also involve editing operations.
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?
No guidance is provided about when to use this tool versus alternatives. It doesn't specify prerequisites (e.g., must be in editing mode first), exclusions, or relationships with sibling tools like logseq_edit_block for entering editing mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pages in the graph with basic metadata
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Repository name (default: current graph) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'basic metadata' but doesn't specify what that includes (e.g., page names, creation dates) or operational details like pagination, rate limits, or error handling. This leaves significant gaps for a tool that lists all pages.
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?
The description is a single, efficient sentence that front-loads the core action and resource without any wasted words. It is appropriately sized for a simple list operation, making it easy for an AI agent to parse quickly.
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?
Given the complexity of listing all pages in a graph, the description is incomplete. With no annotations and no output schema, it fails to explain what 'basic metadata' entails, how results are structured, or potential limitations (e.g., large graphs). This leaves the AI agent with insufficient context for effective use.
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 input schema has 100% description coverage, clearly documenting the optional 'repo' parameter. The description adds no additional parameter details beyond what the schema provides, such as examples or constraints, so it meets the baseline for high schema coverage without enhancing semantics.
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 clearly states the action ('List') and resource ('all pages in the graph') with scope ('basic metadata'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'logseq_get_page' or 'logseq_get_current_page', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'logseq_get_page' (for a single page) or 'logseq_get_current_page' (for the active page). It lacks any context about prerequisites, such as needing an open graph, or exclusions, which limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the currently active page or block in the user's workspace
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data, implying it's read-only, but doesn't clarify aspects like whether it requires user authentication, if it works offline, or what happens if no page is active. This leaves significant gaps for a tool that interacts with user workspace data.
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?
The description is a single, clear sentence that directly states the tool's function without any fluff or redundancy. It's front-loaded and efficiently communicates the core purpose, making it easy to parse quickly.
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?
Given the tool has no parameters, no annotations, and no output schema, the description is minimally adequate but lacks completeness. It doesn't explain what 'currently active' means in context, what format the return value has, or how errors are handled, leaving the agent with unanswered questions about implementation details.
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 input schema has 0 parameters with 100% coverage, so the schema already fully documents that no arguments are needed. The description adds no parameter-specific information, but with zero parameters, the baseline is 4 as it doesn't need to compensate for any gaps.
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 clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('currently active page or block'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'logseq_get_page' or 'logseq_get_current_page_content', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'logseq_get_page' (which might retrieve a specific page) or 'logseq_get_current_page_content' (which might retrieve content instead of metadata). There's no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get hierarchical block structure of current page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states what the tool does but lacks behavioral details: it doesn't specify if this requires an active Logseq session, what happens if no current page exists (error vs. null), the format of 'hierarchical block structure' (e.g., tree vs. list), or any rate limits. The description is minimal and misses key operational context.
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?
The description is a single, clear sentence with zero waste. It front-loads the core action and resource ('Get hierarchical block structure of current page'), making it immediately understandable. Every word earns its place, and there's no fluff or repetition.
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?
Given the lack of annotations and output schema, the description is incomplete for a tool that fetches structured data. It doesn't explain the return format (e.g., JSON tree), error conditions, or dependencies like needing an open page. For a read operation with potential complexity in output, more context is needed to guide effective use.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, avoiding redundancy. A baseline of 4 is applied for zero parameters, as it efficiently omits unnecessary information.
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 clearly states the action ('Get') and resource ('hierarchical block structure of current page'), making the purpose understandable. It distinguishes from siblings like 'logseq_get_page_content' by specifying 'current page' rather than any page. However, it doesn't explicitly contrast with 'logseq_get_current_page' (which might return metadata vs. content), leaving slight ambiguity.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a current page open), exclusions, or comparisons to siblings like 'logseq_get_page_content' (for arbitrary pages) or 'logseq_get_editing_block_content' (for focused editing). Usage is implied by 'current page' but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get content of currently edited block
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a read operation ('Get'), it doesn't specify whether this requires specific permissions, what happens if no block is being edited (e.g., error or null return), or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action ('Get content'), making it easy to scan and understand quickly. Every word earns its place by specifying the exact resource without unnecessary elaboration.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a minimal viable explanation. However, it lacks details on behavioral aspects like error conditions or return format, which would be helpful for an agent to use it correctly. Without annotations or output schema, the description should ideally cover more of these contextual elements.
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 has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't mention parameters, which is correct for this case. It adds value by clarifying the resource ('currently edited block'), though this is more about purpose than parameter semantics.
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 clearly states the verb ('Get') and resource ('content of currently edited block'), making the purpose immediately understandable. It distinguishes from siblings like 'logseq_get_page_content' by specifying 'currently edited block' rather than a named page. However, it doesn't explicitly contrast with 'logseq_get_current_page_content' or 'logseq_edit_block', which slightly limits sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a block must be actively being edited), exclusions, or comparisons to siblings like 'logseq_get_current_page_content' or 'logseq_get_page_content'. Without this context, an agent might struggle to select the right tool in a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed information about a specific page including metadata and content
| Name | Required | Description | Default |
|---|---|---|---|
| include_children | No | Include child blocks in response | |
| src_page | Yes | Page identifier (name, UUID or database ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'retrieve' implies a read-only operation, it doesn't specify whether this requires authentication, has rate limits, or what happens on errors (e.g., if the page doesn't exist). The description mentions 'detailed information' but lacks specifics on response format or potential side effects, leaving significant gaps for a tool with no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the key action ('retrieve') and resource ('detailed information about a specific page'), making it easy to scan and understand quickly.
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?
Given the complexity of retrieving page data with metadata and content, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., structure of metadata, content format), potential limitations, or error handling. For a tool with no structured behavioral hints, this leaves too much ambiguity for effective agent use.
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 100%, meaning the input schema already documents both parameters ('src_page' and 'include_children') with descriptions and examples. The description adds no additional meaning beyond what the schema provides, such as clarifying parameter interactions or usage examples. However, since the schema coverage is high, the baseline score of 3 is appropriate.
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 clearly states the verb 'retrieve' and the resource 'detailed information about a specific page including metadata and content', which is specific and actionable. However, it doesn't explicitly distinguish this tool from sibling tools like 'logseq_get_page_content' or 'logseq_get_all_pages', which reduces the score from a perfect 5.
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?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't explain when to choose 'logseq_get_page' over 'logseq_get_page_content' (which might retrieve just content without metadata) or 'logseq_get_all_pages' (for listing pages). There's no mention of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get block hierarchy for specific page
| Name | Required | Description | Default |
|---|---|---|---|
| src_page | Yes | Page name or UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool gets block hierarchy, but doesn't explain what 'block hierarchy' entails (e.g., structure, format, depth), whether it's read-only (implied by 'Get' but not explicit), or any limitations like rate limits or authentication needs. This leaves significant gaps for a tool with no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence ('Get block hierarchy for specific page') that is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.
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?
Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain the return value (e.g., what 'block hierarchy' looks like), behavioral aspects like safety or performance, or how it differs from sibling tools. For a tool with these contextual gaps, the description should provide more comprehensive information to guide effective use.
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 input schema has 100% description coverage, with 'src_page' clearly documented as 'Page name or UUID' with examples. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.
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 'Get block hierarchy for specific page' clearly indicates a retrieval action ('Get') on a specific resource ('block hierarchy for specific page'), which is better than a tautology. However, it doesn't differentiate from sibling tools like 'logseq_get_page' or 'logseq_get_current_page_content', leaving ambiguity about what distinguishes this tool from other page/content retrieval tools.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to siblings such as 'logseq_get_page' or 'logseq_get_current_page_content', nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert a new block into Logseq. Can create: - Page-level blocks (use is_page_block=true with page name as parent_block) - Nested blocks under existing blocks - Blocks with custom UUIDs for precise reference Supports before/after positioning and property management.
| Name | Required | Description | Default |
|---|---|---|---|
| before | No | Insert before parent | |
| content | Yes | Content of the new block | |
| custom_uuid | No | Custom UUID for block | |
| is_page_block | No | Page-level block flag | |
| parent_block | No | UUID or content of parent block |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits like support for 'before/after positioning and property management,' which are not obvious from the schema alone. However, it lacks details on permissions needed, error conditions, or what happens on failure, leaving gaps for a mutation tool.
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?
The description is appropriately sized and front-loaded, starting with the core action and immediately listing capabilities in a bullet-like structure. Every sentence adds value, though the formatting with colons and dashes could be slightly cleaner for optimal readability.
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?
Given the complexity of a block insertion tool with 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers key use cases and parameters but lacks information on return values, error handling, or integration with sibling tools, leaving some contextual gaps for an agent to operate effectively.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'before/after positioning' (hinting at the 'before' parameter) and 'custom UUIDs' (referencing 'custom_uuid'), but does not provide additional semantics beyond what the schema specifies, meeting the baseline for high coverage.
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 clearly states the specific action ('Insert a new block') and resource ('into Logseq'), distinguishing it from siblings like logseq_create_page (creates pages) and logseq_edit_block (modifies existing blocks). It provides concrete examples of what can be created, making the purpose unambiguous and differentiated.
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?
The description provides clear context on when to use this tool by listing the types of blocks it can create (page-level, nested, with custom UUIDs). However, it does not explicitly state when NOT to use it or name specific alternatives among the sibling tools, such as using logseq_create_page for creating new pages instead of page-level blocks.
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. Dates show when Glama detected each change.
v1.0.0logseq_create_pagelogseq_edit_blocklogseq_exit_editing_modelogseq_get_all_pageslogseq_get_current_pagelogseq_get_current_page_contentlogseq_get_editing_block_contentlogseq_get_pagelogseq_get_page_contentlogseq_insert_blockThe tools have clear distinct purposes for core operations like creating pages, editing blocks, and retrieving content, but there is notable overlap between retrieval tools. Specifically, logseq_get_page and logseq_get_page_content both retrieve page details, and logseq_get_current_page_content and logseq_get_editing_block_content focus on current workspace content, which could cause confusion in selection. Descriptions help differentiate, but the boundaries are not perfectly distinct.
All tool names follow a consistent snake_case pattern with a 'logseq_' prefix, using clear verb_noun combinations such as create_page, edit_block, and get_all_pages. This uniformity makes the tools predictable and easy to parse, with no deviations in style or structure across the set.
With 10 tools, the count is well-scoped for a Logseq server, covering essential operations like page creation, editing, and content retrieval. Each tool serves a specific function without redundancy, fitting within the typical 3-15 range for such a domain, and no tools feel unnecessary or missing for basic interactions.
The tool set provides good coverage for core Logseq workflows, including CRUD-like operations for pages and blocks (create, get, edit, insert). However, there are minor gaps, such as no explicit tools for deleting pages or blocks, updating block content beyond editing mode, or managing properties post-creation, which agents might need to work around using existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal wiki and memory layer for AI assistants. Persistent, structured memory across sessions.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
The Grafbase MCP server sits in front of a GraphQL API and exposes an MCP protocol-compliant interface that allows AI agents and LLMs to explore and query GraphQL APIs using natural language. It provides tools to search schemas, introspect types and fields, and execute GraphQL queries while minimizing context bloat by returning only relevant schema subsets, with built-in support for authentication, authorization, and configurable access control.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dailydaniel/logseq-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
