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., "@tilnote-mcp-server search my notes for MCP"
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.
An MCP (Model Context Protocol) server that lets AI assistants create, read, search, and update notes on Tilnote. Works with Claude Code, Claude Desktop, Google Antigravity, and OpenAI Codex CLI.
Tool | Description |
| Create a new markdown note (saved as draft) |
| Get the full content of a note by page ID |
| List your recent notes with excerpts |
| Search notes by keyword |
| Update the title or content of an existing note |
Tool | Description |
| Create a new book |
| List your books with title, page count, and status |
| Get book details including its list of pages |
| Add an existing note to a book |
| Remove a note from a book |
Related MCP server: SiYuan MCP Server
Node.js 18+ — https://nodejs.org (includes npx)
Go to https://tilnote.io/tilnote-api to generate your API key.
.mcp.json){
"mcpServers": {
"tilnote": {
"command": "npx",
"args": ["-y", "tilnote-mcp-server"],
"env": {
"TILNOTE_API_KEY": "your_api_key_here"
}
}
}
}OS | Config file location |
macOS |
|
Windows |
|
{
"mcpServers": {
"tilnote": {
"command": "npx",
"args": ["-y", "tilnote-mcp-server"],
"env": {
"TILNOTE_API_KEY": "your_api_key_here"
}
}
}
}Open: Manage MCP Servers → View raw config → ~/.gemini/antigravity/mcp_config.json
{
"mcpServers": {
"tilnote": {
"command": "npx",
"args": ["-y", "tilnote-mcp-server"],
"env": {
"TILNOTE_API_KEY": "your_api_key_here"
}
}
}
}Restart Antigravity after saving.
Add to ~/.codex/config.toml:
[mcp_servers.tilnote]
command = "npx"
args = ["-y", "tilnote-mcp-server"]
env = { TILNOTE_API_KEY = "your_api_key_here" }Variable | Required | Description |
| Yes | Your Tilnote API key |
MIT
Tilnote에 노트를 생성, 조회, 검색, 수정할 수 있는 MCP (Model Context Protocol) 서버입니다. Claude Code, Claude Desktop, Google Antigravity, OpenAI Codex CLI와 연동하여 사용합니다.
도구 | 설명 |
| 마크다운 노트 생성 (초안으로 저장) |
| 페이지 ID로 노트 전체 내용 조회 |
| 최근 노트 목록과 요약 조회 |
| 키워드로 노트 검색 |
| 기존 노트의 제목 또는 내용 수정 |
도구 | 설명 |
| 새 북 생성 |
| 북 목록 조회 (제목, 페이지 수, 공개 여부) |
| 특정 북 상세 조회 (포함된 노트 목록 포함) |
| 기존 노트를 북에 추가 |
| 북에서 노트 제거 |
Node.js 18+ — https://nodejs.org 에서 설치 (npx 포함)
https://tilnote.io/tilnote-api 에서 API 키를 발급받으세요.
.mcp.json){
"mcpServers": {
"tilnote": {
"command": "npx",
"args": ["-y", "tilnote-mcp-server"],
"env": {
"TILNOTE_API_KEY": "발급받은_API_키"
}
}
}
}OS | 설정 파일 위치 |
macOS |
|
Windows |
|
{
"mcpServers": {
"tilnote": {
"command": "npx",
"args": ["-y", "tilnote-mcp-server"],
"env": {
"TILNOTE_API_KEY": "발급받은_API_키"
}
}
}
}Manage MCP Servers → View raw config → ~/.gemini/antigravity/mcp_config.json 열기
{
"mcpServers": {
"tilnote": {
"command": "npx",
"args": ["-y", "tilnote-mcp-server"],
"env": {
"TILNOTE_API_KEY": "발급받은_API_키"
}
}
}
}저장 후 Antigravity를 재시작하세요.
~/.codex/config.toml 에 추가:
[mcp_servers.tilnote]
command = "npx"
args = ["-y", "tilnote-mcp-server"]
env = { TILNOTE_API_KEY = "발급받은_API_키" }변수 | 필수 | 설명 |
| 필수 | 틸노트 API 키 |
MIT
Add an existing note (page) to a Tilnote book.
| Name | Required | Description | Default |
|---|---|---|---|
| bookId | Yes | The book ID to add the page to | |
| pageId | Yes | The page ID of the note to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It fails to mention what happens if the page already exists in the book, or if IDs are invalid, leaving critical behavior unknown.
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 very concise at one sentence, but lacks any structural elements like headings or bullet points. It is efficient but not ideally structured for quick scanning.
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 simple tool with 2 required params and no output schema, the description provides minimal context. It does not explain the nature of the page-to-book relationship or clarify outcomes, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The tool description adds no additional meaning beyond these schema details, so baseline 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 action (add) and the resources (existing note to a Tilnote book). It effectively distinguishes from siblings like create_note (creates new) and remove_page_from_book (removes).
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 on when to use this tool versus alternatives, or prerequisites such as ensuring the book and note exist. This lack of context could lead to misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new book on Tilnote. Returns the book ID and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Book title (max 500 chars) | |
| description | No | Short description of the book (max 500 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to cover safety or read-only behavior, the description carries the burden. It only mentions the output but fails to disclose side effects, authentication needs, or constraints beyond the schema (e.g., idempotency, rate limits).
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 two sentences long with no unnecessary words. It front-loads the core action and briefly notes the return format, making it efficient.
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 simple creation tool with only two parameters and no output schema, the description is largely adequate. It names the return values and the purpose, though it could elaborate on immediate availability or potential duplicates.
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 for its two parameters, so the description adds minimal value beyond the schema. It does mention the return value, but that's not parameter-related. Baseline 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 action ('Create'), the resource ('a new book'), and the platform ('Tilnote'), while also specifying the return values ('book ID and URL'). This differentiates it from sibling tools like 'add_page_to_book' or 'get_book'.
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 on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The description simply states the function without contextual help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a markdown note on Tilnote. The note is saved as a draft.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Note title (max 500 chars) | |
| content | Yes | Markdown body content only. Do NOT include the title in content — it is set separately via the title field. | |
| sourceUrl | No | Source URL (http/https) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only reveals that notes are saved as drafts, but omits other aspects like permissions, rate limits, or any side effects. This is 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 extremely concise with two short sentences that convey the core purpose without extraneous information. Every word earns its place.
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?
The description lacks any indication of what the tool returns or how to retrieve the created note. Since there is no output schema, this is a significant gap that forces the agent to guess or use separate lookup tools without guidance.
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 provides full descriptions for all parameters (100% coverage), so the description adds no additional semantic value beyond the schema. Baseline score 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 tool creates a markdown note on Tilnote and specifies it is saved as a draft. This effectively distinguishes it from sibling tools like update_note and add_page_to_book.
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 implies this tool is used to create a new note and notes are saved as drafts, but does not explicitly state when to use it versus alternatives like update_note or when not to use it. Minimal guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific Tilnote book including its list of pages.
| Name | Required | Description | Default |
|---|---|---|---|
| bookId | Yes | The book ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes what is returned but does not state read-only nature, side effects, authentication needs, or rate limits. Since it's a retrieval, read-only is implied but not explicit.
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?
Single sentence, no fluff. Front-loaded with verb and resource. Every word adds value.
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 simple tool with one parameter and no output schema, the description is fairly complete: it states what it retrieves (details + pages). Could optionally mention return format or pagination, but missing info is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for 'bookId' as 'The book ID to retrieve'. The tool description adds 'including its list of pages', which is outcome info but does not enhance parameter semantics beyond the schema. Baseline 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 'Get', the resource 'specific Tilnote book', and includes what is returned ('details including its list of pages'). It distinguishes from sibling tools like 'list_books' (which lists all) and 'add_page_to_book' (modification).
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 implicitly suggests usage when details of a single book are needed, but does not provide explicit guidance on when to use vs. alternatives like 'list_books' or what prerequisites exist. No when-not-to-use or exclusionary language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full content of a specific Tilnote note by its page ID.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The page ID of the note to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description simply says 'Get the full content' without disclosing behavioral traits such as failure modes, permissions, rate limits, or idempotency.
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, and front-loaded sentence with no redundant words.
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?
There is no output schema, and the description does not specify the return format, leaving the agent uninformed about what to expect from the response.
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 covers the sole parameter with a description; the tool's description adds minimal meaning ('by its page ID') beyond what the schema already 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 verb 'Get' and resource 'full content of a specific Tilnote note', and distinguishes from sibling tools like create_note, update_note, list_notes, and search_notes.
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 implies usage for retrieving a single note's content but lacks explicit guidance on when to use or not, and does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your Tilnote books. Returns title, page count, and URL for each book.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of books to return (default 20, max 50) | |
| page | No | Page number for pagination (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists returned fields but omits behavioral details like pagination defaults, ordering, or scope (e.g., user vs workspace).
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?
Single sentence, front-loaded with action and resource. No unnecessary words, appropriately concise.
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 simplicity (2 optional params, no output schema), description covers core purpose and return format. Minor gap: doesn't mention pagination defaults (limits, page) but schema already defines them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. Description adds no extra meaning beyond schema, meeting baseline but not exceeding it.
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?
Description clearly states the action (list), resource (books), and returned fields (title, page count, URL), distinguishing it from siblings like get_book or list_notes.
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 on when to use this tool versus alternatives such as get_book or search_notes. Context signals show multiple sibling tools that could be confused.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your Tilnote notes. Returns recent notes with title, excerpt, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of notes to return (default 20, max 50) | |
| page | No | Page number for pagination (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions 'recent' but does not specify ordering, pagination behavior beyond the schema, or any side effects. The description adds little beyond the purpose.
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, concise sentence that efficiently conveys the tool's purpose and output, with no wasted words.
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?
The description specifies returned fields but lacks details on ordering, total results, or error handling. For a simple list tool with no output schema, the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters documented. The description does not add additional meaning beyond what the schema provides, so a 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 'List' and resource 'your Tilnote notes', and specifies the returned fields (title, excerpt, URL). It distinguishes from sibling tools like get_note (single note) and search_notes (search).
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 implies listing recent notes, which is distinct from search_notes (filtered queries) and get_note (single note), but it does not explicitly mention when to use or not use this tool, nor does it name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a note (page) from a Tilnote book.
| Name | Required | Description | Default |
|---|---|---|---|
| bookId | Yes | The book ID to remove the page from | |
| pageId | Yes | The page ID of the note to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as destructiveness, reversibility, or side effects. The tool likely performs a destructive operation, but this is not stated.
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?
A single, concise sentence conveys the core purpose with no unnecessary words. Efficiently front-loaded.
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 minimal. It does not explain post-removal behavior, error conditions, or any confirmation. Incomplete for a destructive operation.
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?
Input schema has 100% coverage with clear descriptions for both parameters (bookId and pageId). The description adds no extra meaning beyond the schema, so baseline score is 3.
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 ('Remove') and the resource ('a note (page) from a Tilnote book'). It effectively distinguishes from sibling tools like 'add_page_to_book' and 'create_note'.
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 on when to use this tool versus alternatives, nor any prerequisites or context for removal. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search your Tilnote notes by keyword (searches title and content).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search keyword | |
| limit | No | Max results (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the search scope (title and content) without disclosing behavior like result format, case sensitivity, or pagination, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the essential purpose with no superfluous text.
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 simple search tool with no output schema, the description covers basic purpose but omits details about the response format or results handling, making it adequate but not fully complete.
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%, and the tool description repeats the schema's 'keyword' mention without adding new semantics; thus baseline value is maintained.
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 searches notes by keyword across title and content, distinguishing it from sibling tools like list_notes (lists all) and get_note (retrieves by ID).
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 does not provide explicit guidance on when to use this tool versus alternatives; it is implied for keyword searches but lacks explicit comparisons or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the title or content of an existing Tilnote note.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The page ID of the note to update | |
| title | No | New title (max 500 chars) | |
| content | No | New markdown content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Update' but does not specify whether updates are partial or full replacements, whether previous versions are preserved, or any auth or rate limit constraints. The word 'or' may mislead about updating multiple fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, making it very concise with no wasted words. However, it could be improved by clarifying the 'or/and' ambiguity. Still, it is well-structured and front-loaded.
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 output schema and no annotations, the description should cover return values (e.g., updated note or success status) and any side effects. It does not. For a mutation tool, more context is needed to ensure correct invocation, such as whether the update is idempotent.
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 each parameter. The tool description adds minimal value beyond repeating 'title' and 'content', and the phrase 'title or content' slightly contradicts the schema which allows both to be provided simultaneously. Baseline 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 action ('update') and the resource ('existing Tilnote note'), and mentions the specific fields (title or content). It differentiates from sibling tools like 'create_note' (creation) and 'get_note' (retrieval).
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 does not provide guidance on when to use this tool versus alternatives, such as 'create_note' for new notes or 'search_notes' for finding notes. It also lacks prerequisites (e.g., note must exist) and does not clarify that both title and content can be updated simultaneously despite the schema allowing it.
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.
v0.2.1add_page_to_bookcreate_bookcreate_noteget_bookget_notelist_bookslist_notesremove_page_from_booksearch_notesupdate_noteEach tool targets a distinct action on either notes or books, with no overlap. For example, create_note and update_note are clearly separate, and add_page_to_book/remove_page_from_book are specific to book-page relationships.
All tools follow a consistent verb_noun pattern (e.g., create_book, list_notes, get_note, search_notes), making it predictable and easy for an agent to infer functionality.
With 10 tools, the set is well-scoped for a note-taking and book organization domain. It covers core operations without being excessively large or too minimal.
While the tool set covers creation, retrieval, and updates, it lacks delete operations for notes and books (no delete_note, delete_book). This is a notable gap that may cause dead ends in workflows requiring removal.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI access to your aNotepad online notes: read, search, write, and organize via 22 tools.
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Create, search, and update notes in an xNotepad AI notebook, with semantic search and AI Q&A.
Create, search and manage Knowtis collaborative notes from AI assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wisdomcrane/tilnote-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
