Skip to main content
Glama
Sign In
GetNote MCP Server

GetNote MCP Server

by iswalle
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_topics

Retrieve paginated knowledge base topics the user created, owns, or joined, filtering by scope, name query, book ID, or author. Use it to locate book spaces and verify titles before follow-up lookups.

Instructions

获取用户创建、拥有或加入的知识库列表，默认DEFAULT；查书名/书籍作者显式scope=BOOKSPACE，query只匹配书名、author匹配书籍作者，二者AND，只有作者线索就只传author。返回topics[]、has_more、total，完整分页并核对book_info。无匹配且用户未限定只查自有时，用list_subscribe_topics保留全部条件补查；仍无匹配再按list_notes的引用来源路线补查，不能把空书库当账号没有划线。用户限定具体知识库时保留原范围；来源作者冲突保留为待核验候选。

Input Schema

NameRequiredDescriptionDefault
pageNo页码，从 1 开始（默认 1）
queryNo只匹配知识库名/书名，不匹配作者；与 author 同时传时为 AND。多候选须核对书名、作者和 book_id
scopeNo知识库类型，默认 DEFAULTDEFAULT
authorNo书籍作者，限 BOOKSPACE；只有作者线索时只传 author，不猜书名或把作者填进 query
book_idNo书籍 ID 字符串，限 BOOKSPACE
page_sizeNo每页 1–100 条，默认 20

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.10.1
    • addedInput schema / properties / author
      Added value: +{
+  "description": "书籍作者，限 BOOKSPACE；只有作者线索时只传 author，不猜书名或把作者填进 query",
+  "type": "string"
+}
    • addedInput schema / properties / book_id
      Added value: +{
+  "description": "书籍 ID 字符串，限 BOOKSPACE",
+  "type": "string"
+}
    • addedInput schema / properties / page_size
      Added value: +{
+  "description": "每页 1–100 条，默认 20",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / query
      Added value: +{
+  "description": "只匹配知识库名/书名，不匹配作者；与 author 同时传时为 AND。多候选须核对书名、作者和 book_id",
+  "type": "string"
+}
    • addedInput schema / properties / scope
      Added value: +{
+  "default": "DEFAULT",
+  "description": "知识库类型，默认 DEFAULT",
+  "enum": [
+    "DEFAULT",
+    "CUSTOMER",
+    "BOOKSPACE",
+    "TEAMSPACE"
+  ],
+  "type": "string"
+}
  2. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are supplied, so the description must carry the full behavioral burden. It discloses the return shape (topics[], has_more, total), pagination behavior, and the meaning of an empty result. It does not discuss permission or auth requirements, but for a read-only listing tool that is a minor gap.

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

Conciseness4/5

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

Purpose comes first, followed by scope and matching rules, then the fallback chain; the structure is very efficient for such a dense description. It reads as long, semicolon-joined clauses rather than as clean sentences, which slightly hurts scanability, but no sentence is wasted.

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

Completeness4/5

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

There is no output schema and no annotations, so the description reasonably compensates by naming the return fields and the pagination flags. The fallback chain and the warning about empty results close the main behavioral gaps. It could still say more about what a topic object contains and what the book_info check involves.

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 most of the value is already in the structured fields. The description restates the query/author AND semantics, the BOOKSPACE restriction, and 'only pass author when you have an author clue', nearly all of which also appear in the schema parameter descriptions, so it adds little beyond what the schema already provides. Baseline 3 is appropriate.

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

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource (retrieve the list of knowledge bases the user created, owns, or joined) and immediately pins down the default scope. It also distinguishes itself from the sibling list_subscribe_topics by describing the exact situation in which that sibling is the correct fallback.

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

Usage Guidelines5/5

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

The description gives explicit routing rules: use scope=BOOKSPACE when the clue is a book title or author, pass only author when the only clue is an author, fall back to list_subscribe_topics when there is no match and the user has not restricted the search to owned topics, and only then fall back to the reference sources of list_notes. It also states a negative rule (an empty library must not be reported as the account having no highlights), which is exactly the kind of exclusion an agent needs.

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

Deploy Server

Other Tools