Logseq MCP Server

by dearcloud09

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in the Logseq domain, such as create_page vs. read_page vs. update_page vs. delete_page for page lifecycle, and get_backlinks vs. get_graph vs. search_pages for different query types. No tools appear to overlap or cause confusion in selection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as append_to_page, create_journal, and get_backlinks. This predictable naming scheme makes it easy for an agent to understand and use the tools without ambiguity or style mixing.
Tool Count5/5
With 11 tools, the server is well-scoped for managing a knowledge graph like Logseq, covering essential operations from CRUD for pages and journals to advanced queries like backlinks and graph data. Each tool earns its place without feeling excessive or insufficient for the domain.
Completeness5/5
The tool set provides complete coverage for the Logseq domain, including full CRUD lifecycle for pages and journals, listing, reading, updating, deleting, and specialized operations like backlinks, graph retrieval, and search. There are no obvious gaps that would hinder agent workflows in this context.
Average 2.8/5 across 11 of 11 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on June 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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. '페이지 삭제' only indicates a destructive operation but provides no information about permissions required, whether deletion is permanent or reversible, what happens to linked content, rate limits, or error conditions. For a destructive operation with zero annotation coverage, this is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this represents under-specification rather than effective brevity. The description fails to provide necessary context for a destructive operation. Every word should earn its place, but here the minimal content fails to adequately describe the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is completely inadequate. It doesn't explain what constitutes a 'page' in this context, what the deletion entails, whether there are confirmation steps, what the response looks like, or any error conditions. Given the complexity of a delete operation and the lack of structured documentation, this description fails to provide necessary context.
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 description coverage is 100%, with the single parameter 'path' clearly documented as '삭제할 페이지 경로 또는 이름' (path or name of page to delete). The description adds no additional parameter information beyond what the schema already provides. With complete schema coverage, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '페이지 삭제' (delete page) is a tautology that merely restates the tool name in Korean. It doesn't specify what type of page or resource is being deleted, nor does it distinguish this tool from potential alternatives like 'update_page' or other deletion operations. While the verb 'delete' is clear, the description lacks any additional context about the resource being operated on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With multiple sibling tools including 'update_page', 'read_page', and 'list_pages', there's no indication of when deletion is appropriate versus modification or retrieval. No prerequisites, constraints, or comparison to other tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'modify existing page content' which implies a mutation operation, but it doesn't disclose critical traits like permission requirements, whether changes are reversible, potential side effects (e.g., overwriting content), or error handling. This is a significant gap for a mutation tool with zero 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, efficient sentence in Korean ('기존 페이지 내용 수정') that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
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's complexity (mutation operation with 3 parameters, nested objects, and no output schema), the description is incomplete. It lacks information on behavioral traits, output expectations, and usage guidelines, which are crucial for an agent to invoke this tool correctly in context with siblings like 'append_to_page' and 'delete_page'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (path, content, properties). The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter interactions, format details, or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '기존 페이지 내용 수정' (modify existing page content) clearly states the verb (modify) and resource (page content), but it's vague about scope and doesn't distinguish from siblings like 'append_to_page' or 'create_page'. It's adequate but lacks specificity about what 'modify' entails compared to other page operations.
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 like 'append_to_page' (for adding content) or 'create_page' (for new pages). The description implies it's for existing pages but doesn't clarify prerequisites, exclusions, or typical use cases, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 tool appends content to the end of an existing page, implying a mutation operation, but lacks details on permissions, side effects (e.g., overwriting), rate limits, or response format. The description is minimal and doesn't disclose key behavioral traits beyond the basic action.
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, efficient sentence in Korean that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with zero waste. Every part of the sentence earns its place by conveying the core action.
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 2 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral context (e.g., error handling, permissions), usage guidelines relative to siblings, and output details. For a mutation tool with minimal structured data, the description should provide more 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?
Schema description coverage is 100%, with both parameters ('path' and 'content') documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., no examples or constraints). Baseline is 3 since the schema does the heavy lifting, but no extra value is added.
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 '기존 페이지 끝에 내용 추가' clearly states the action (append) and target (existing page), specifying it adds content to the end. It distinguishes from siblings like 'create_page' (new page) and 'update_page' (modify existing content), though it doesn't explicitly name alternatives. The purpose is specific but lacks 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 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 like 'update_page' or 'create_page'. It implies usage for appending to existing pages but doesn't specify prerequisites (e.g., page must exist), exclusions, or contextual triggers. No explicit when/when-not statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It states the creation action but doesn't disclose permissions needed, whether creation overwrites existing entries, what happens on failure, or format of results. For a mutation tool with zero annotation coverage, this is insufficient.
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?
Single sentence, zero waste, front-loaded with core purpose. Every word earns its place - specifies action, resource, and temporal scope efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a successful creation returns, error conditions, or behavioral constraints. Given the mutation nature and lack of structured metadata, more context is needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description mentions 'today or specific date' which aligns with the date parameter's description, but adds no additional semantic context beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the action ('create') and resource ('journal page') with specific temporal scope ('today or specific date'). It distinguishes from generic 'create_page' by specifying journal creation, though doesn't explicitly differentiate from other journal-related tools like 'get_journal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'create_page' or 'append_to_page'. The description mentions temporal scope but doesn't provide context about prerequisites, when-not-to-use scenarios, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states this creates a new page but doesn't disclose important traits like: whether this requires specific permissions, what happens if a page with the same name already exists, whether changes are permanent/destructive, or what the response format looks like. The Logseq property mention is useful but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two short phrases. It's front-loaded with the core purpose ('새 페이지 생성') followed by an important capability detail. While efficient, it might be too terse given the tool's complexity as a creation operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens on success/failure, return values, error conditions, or important behavioral constraints. Given 3 parameters (including a nested object) and the creation nature, more context about permissions, idempotency, and response format is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema - it mentions Logseq properties correspond to the 'properties' parameter, but doesn't provide additional semantic context about format, constraints, or usage patterns.
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 clearly states the action ('새 페이지 생성' - create new page) and resource (page), with the additional detail that it can include Logseq properties. It distinguishes from siblings like 'append_to_page' (modifies existing) and 'create_journal' (different resource type). However, it doesn't explicitly contrast with 'update_page' which might also create pages in some contexts.
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 like 'create_journal' for journal pages or 'update_page' for modifying existing pages. It mentions Logseq properties but doesn't explain when this capability is relevant versus using simpler creation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves pages that reference a specific page, implying a read-only operation, but doesn't disclose any behavioral traits such as permissions needed, rate limits, pagination, or error handling. For a tool with no annotations, this is a significant gap, as it leaves key operational details unspecified.
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, clear sentence in Korean: '특정 페이지를 참조하는 모든 페이지 조회.' It is front-loaded with the core purpose and has no unnecessary words, making it highly efficient and easy to understand. Every part of the sentence earns its place by directly conveying the tool's function.
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 complexity of retrieving backlinks (which involves relationships between pages), the lack of annotations and output schema means the description is incomplete. It doesn't explain what the return values look like (e.g., list of pages, metadata), any limitations, or how to handle errors. For a tool with no structured output information, this leaves significant gaps in understanding its behavior and results.
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% description coverage, with the 'path' parameter documented as '페이지 경로 또는 이름' (page path or name). The description doesn't add any meaning beyond this, such as format examples or constraints. Since the schema already provides adequate parameter information, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 clearly states the tool's purpose: '특정 페이지를 참조하는 모든 페이지 조회' translates to 'Retrieve all pages that reference a specific page.' This specifies the verb (retrieve/reference) and resource (pages), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_graph' or 'search_pages,' which might have overlapping functionality, so it doesn't reach a score of 5.
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. It doesn't mention any prerequisites, exclusions, or comparisons with sibling tools such as 'get_graph' (which might show relationships) or 'search_pages' (which might find pages based on content). This lack of context leaves the agent to infer usage, resulting in a minimal score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what data is included (links/backlinks/tag relationships) but doesn't disclose critical behavioral traits like whether this is a read-only operation, performance characteristics, pagination, error conditions, or authentication requirements. For a data retrieval tool with zero annotation coverage, this leaves significant gaps.
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 extremely concise - a single sentence in Korean that efficiently communicates the core functionality. Every word earns its place with no wasted text, making it front-loaded and easy to parse despite the language difference.
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 complexity of graph data retrieval and the absence of both annotations and output schema, the description is insufficient. It doesn't explain what format the graph data returns, how relationships are represented, what happens when parameters are omitted, or any limitations of the tool. For a graph query tool with no structured output documentation, this leaves too many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what the schema provides - it doesn't explain how 'center' and 'depth' interact or provide examples of valid values. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose as 'retrieving page connection graph data' with specific components mentioned (links/backlinks/tag relationships). It uses a specific verb ('retrieve') and resource ('page connection graph data'), though it doesn't explicitly differentiate from sibling tools like 'get_backlinks' which might overlap in functionality.
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. With sibling tools like 'get_backlinks' and 'list_pages' available, there's no indication of when this graph retrieval tool is preferable or what specific use cases it addresses compared to those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves journal pages, implying a read-only operation, but doesn't mention any behavioral traits such as authentication needs, rate limits, error handling, or what happens if no page exists for the date. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded in a single sentence: '오늘 또는 특정 날짜의 저널 페이지 조회'. It efficiently conveys the core purpose without unnecessary words. However, it could be slightly improved by structuring to highlight key distinctions, but overall it's appropriately sized and clear.
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's complexity (a read operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., page content, metadata, or error if missing), how it interacts with siblings, or any prerequisites. For a tool in this context, more detail is needed to fully understand its use and limitations.
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 adds minimal meaning beyond the input schema. It mentions '오늘 또는 특정 날짜' (today or a specific date), which aligns with the 'date' parameter in the schema (described as '날짜 (YYYY-MM-DD, 기본값: 오늘)'). Since schema description coverage is 100%, the baseline is 3, and the description doesn't provide additional syntax, format details, or constraints beyond what's already in 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 clearly states the tool's purpose: '오늘 또는 특정 날짜의 저널 페이지 조회' (retrieve journal page for today or a specific date). It specifies the verb '조회' (retrieve/view) and resource '저널 페이지' (journal page), making the action clear. However, it doesn't explicitly differentiate from siblings like 'read_page' or 'list_pages', which might also retrieve pages.
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. It mentions retrieving journal pages by date, but doesn't clarify if this is for journal-specific pages only, how it differs from 'read_page' (which might read any page), or when to choose other siblings like 'list_pages' for broader queries. No explicit when/when-not or alternative recommendations are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '조회' (retrieve/read) implies a read-only operation, it doesn't explicitly state safety aspects like whether it requires authentication, has rate limits, or what happens if the page doesn't exist. For a read tool with zero annotation coverage, this leaves significant gaps in understanding its behavior beyond the basic action.
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, efficient sentence in Korean that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, with every word contributing to understanding the action. This exemplifies conciseness, earning a top score.
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's complexity (a read operation with one parameter) and the lack of annotations and output schema, the description is incomplete. It doesn't cover what the return values include (e.g., format of content/metadata), error conditions, or behavioral traits like idempotency. For a tool in a server with multiple siblings, more context is needed to ensure the agent can use it effectively.
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% description coverage, with the 'path' parameter well-documented in the schema itself. The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter usage, constraints, or examples. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
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 clearly states the tool's purpose as retrieving both content and metadata for a specific page ('특정 페이지의 전체 내용과 메타데이터 조회'), which translates to 'Retrieve the full content and metadata of a specific page.' This is a specific verb+resource combination that distinguishes it from siblings like list_pages (listing) or search_pages (searching). However, it doesn't explicitly differentiate from get_journal or get_backlinks, which might also retrieve content, so it's not 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.
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. It doesn't mention prerequisites, such as needing an existing page, or compare it to siblings like get_journal (which might retrieve journal-specific content) or update_page (which modifies content). Without any context on usage scenarios or exclusions, the agent must infer from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions search functionality and filter support but doesn't disclose behavioral traits like whether this is a read-only operation, how results are returned (e.g., pagination, format), performance considerations, or error handling. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 extremely concise with just one sentence in Korean, efficiently stating the purpose and key features (tag and folder filter support). Every word earns its place, and it's front-loaded with the core functionality. No unnecessary details or redundancy are present.
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 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of pages, metadata), how results are structured, or any limitations (e.g., search scope, performance). For a search tool with moderate complexity and no structured output information, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (query, tags, folder) with descriptions and constraints. The description adds minimal value by mentioning tag and folder filters but doesn't provide additional semantics beyond what's in the schema. With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches page content/titles and mentions support for tag and folder filters. It specifies the verb ('검색' - search) and resource ('페이지 내용/제목' - page content/titles), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_pages' or 'get_journal' which might also retrieve page information.
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 like 'list_pages' or 'read_page'. It mentions tag and folder filter support, which implies usage for filtered searches, but doesn't specify scenarios, prerequisites, or exclusions. Without explicit when/when-not instructions, usage context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns metadata but doesn't disclose important behavioral traits: whether it's read-only (implied but not stated), pagination or rate limits, authentication requirements, error conditions, or what happens with large graphs. For a listing tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two short sentences that efficiently communicate the core functionality and return values. Every word earns its place with no redundant information. It's appropriately sized for a simple listing tool and front-loads the essential information.
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?
Given the tool's low complexity (single optional parameter) and 100% schema coverage, the description is reasonably complete for basic understanding. However, with no output schema and no annotations, it should ideally provide more context about the return format structure, pagination, or limitations. The description covers the 'what' but leaves gaps in the 'how' and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'folder' fully documented in the schema with enum values and description. The description doesn't add any parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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 clearly states the action ('목록 조회' - list retrieval) and resource ('Graph 내 모든 페이지' - all pages in the graph), and specifies the returned metadata fields. It distinguishes itself from siblings like 'search_pages' (filtered search) and 'read_page' (single page content) by emphasizing comprehensive listing of all pages with metadata. However, it doesn't explicitly contrast with 'get_graph' which might also provide page information.
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 a complete list of pages with metadata rather than filtered results (contrasting with 'search_pages') or single-page operations. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_graph' or provide any exclusion criteria. The context is clear but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![logseq-mcp MCP server](https://glama.ai/mcp/servers/dearcloud09/logseq-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dearcloud09/logseq-mcp)

Score Badge

Copy to your README.md:

[![logseq-mcp MCP server](https://glama.ai/mcp/servers/dearcloud09/logseq-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dearcloud09/logseq-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/dearcloud09/logseq-mcp'

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