What can you do with this server?

Pocket Notes MCP Server is a local shopping memo manager. It provides tools to create, list, analyze, and summarize notes, stored in a JSON file. Tools * list_notes: List notes, optionally filtered by tag. * create_note: Create a note with title, body, and tags. * analyze_notes: Count notes per tag, with MCP progress notifications and cancellation support. * summarize_note: Summarize a note using the host's LLM via MCP sampling. * create_note_interactive: Create a note through an interactive form via MCP elicitation. * list_workspace_roots: List workspace folders from the client. Resources * notes://catalog: Full list of all notes. * notes://note/{id}: Full content of a specific note. Prompts * prepare_shopping: Organize notes into shopping lists in styles: simple, checklist, budget, meal. Other Features * Completion suggestions for note IDs and organization styles. * Notifications on note creation and list change subscriptions. * Logging via stderr.

How do I use Pocket Notes MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pocket Notes MCP list my notes" 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.

Pocket Notes MCP

by fredisbusy

Overview Schema Related Servers Score Discussions

TypeScript

Local

Pocket Notes MCP

장보기 메모를 예제로 MCP를 쉽게 배우는 작은 TypeScript 프로젝트입니다.

익숙한 장보기 흐름만 알면 됩니다.

장보기 메모 보기 → 새 메모 만들기 → 분류별로 확인 → 체크리스트 만들기

메모는 로컬 data/notes.json 파일에 저장됩니다. 데이터베이스나 외부 서비스는 사용하지 않습니다.

먼저 해볼 것

MCP Host에 서버를 연결한 뒤 아래처럼 요청해 보세요.

"저장된 장보기 메모를 보여줘."
"우유 1팩과 달걀 10개를 이번 주 장보기 메모로 저장해 줘."
"식료품으로 분류된 메모만 보여줘."
"이 메모를 매장에서 볼 체크리스트로 만들어 줘."

Related MCP server: API MCP Server

장보기로 배우는 MCP

MCP 개념	장보기 예제
Tools	메모 보기, 만들기, 분류 확인
Structured output	장보기 메모 목록을 JSON 형태로 반환
Resources	저장된 메모 전체 또는 하나를 읽기
Resource links	새 메모를 만들면 바로 읽을 수 있는 URI 반환
Prompts	메모를 체크리스트·절약 목록·식사 계획으로 정리
Completion	메모 ID와 정리 방식을 추천
Notifications	새 메모가 생겼음을 Client에 알림
Progress / cancellation	여러 메모의 분류를 확인하는 진행 상황
Multi-round-trip input	Sampling·Elicitation·Roots 입력을 받아 원 요청 재실행
Subscriptions	`subscriptions/listen`으로 메모 목록 변경 알림
Cache hints	목록·Resource·Discovery 결과의 TTL과 공개 범위
Logging	stdio의 `stderr`로 메모 생성 이벤트 기록

Tools, Resources, Prompts가 프로젝트의 핵심입니다. 최신 2026-07-28 프로토콜에서는 server/discover와 요청별 capability를 사용하고, Client 입력은 multi-round-trip input_required 결과로 요청합니다. Sampling과 Roots는 deprecated 예제를 이해하기 위해 남겨 두었으며 Client가 해당 입력 요청을 지원할 때만 작동합니다.

주요 기능

Tools

이름	하는 일
`list_notes`	저장된 장보기 메모 보기
`create_note`	새 장보기 메모 만들기
`analyze_notes`	분류별 메모 수 확인
`summarize_note`	Host 모델로 메모를 짧게 정리
`create_note_interactive`	입력 폼으로 메모 만들기
`list_workspace_roots`	Client가 공개한 작업 폴더 보기

Resources

notes://catalog
notes://note/{id}

notes://catalog는 전체 목록이고, notes://note/{id}는 메모 하나의 전체 내용입니다.

Prompt

prepare_shopping은 저장된 메모를 다음 방식으로 정리합니다.

simple: 살 것만 짧게
checklist: 매장에서 체크할 목록으로
budget: 꼭 필요한 것과 나중에 살 것으로
meal: 만들 수 있는 식사와 빠진 재료로

실행하기

요구사항:

Node.js 24 LTS 권장
Node.js 22 LTS도 호환
pnpm 10 이상

cd /Users/home/Projects/pocket-notes-mcp
pnpm install
pnpm check

개발 모드:

pnpm dev

아무 출력 없이 실행을 기다리는 것이 정상입니다. stdio MCP 서버는 터미널에서 직접 사용하는 CLI가 아니라 MCP Host의 JSON-RPC 메시지를 기다립니다.

빌드된 서버 실행:

pnpm build
pnpm start

MCP Host에 연결하기

제품마다 설정 모양은 조금 다르지만 필요한 값은 같습니다.

{
  "mcpServers": {
    "pocket-notes": {
      "command": "node",
      "args": [
        "/Users/home/Projects/pocket-notes-mcp/dist/index.js"
      ],
      "env": {
        "POCKET_NOTES_FILE": "/Users/home/Projects/pocket-notes-mcp/data/notes.json"
      }
    }
  }
}

POCKET_NOTES_FILE을 생략하면 현재 작업 폴더의 data/notes.json을 사용합니다.

MCP Inspector로 살펴보기

pnpm build
npx @modelcontextprotocol/inspector \
  node /Users/home/Projects/pocket-notes-mcp/dist/index.js

Inspector에서는 다음 순서로 보면 쉽습니다.

list_notes Tool 호출
notes://catalog Resource 읽기
create_note로 메모 만들기
반환된 notes://note/{id} 링크 읽기
prepare_shopping Prompt를 checklist 방식으로 실행

프로젝트 구조

pocket-notes-mcp/
├── src/
│   ├── index.ts                 stdio 연결
│   ├── server.ts                MCP 서버 조립
│   ├── register-tools.ts        기본 Tools
│   ├── register-client-tools.ts Sampling, Elicitation, Roots
│   ├── register-resources.ts    장보기 Resources
│   ├── register-prompts.ts      장보기 Prompt와 Completion
│   ├── note-store.ts            JSON 파일 저장소
│   └── note.ts                  메모 타입과 Markdown 변환
├── data/
│   └── notes.json               장보기 예제
├── tests/                       실제 MCP 연결 테스트
└── scripts/
    └── stdio-smoke.ts           실제 프로세스 연결 확인

파일은 MCP 개념별로만 나눴습니다. 학습에 필요하지 않은 프레임워크, 데이터베이스, DI 컨테이너는 넣지 않았습니다.

테스트

pnpm test

테스트는 함수만 따로 호출하지 않습니다. 실제 MCP Client와 Server를 메모리에서 연결해 Tool, Resource, Prompt, Completion과 양방향 기능을 확인합니다.

전체 검증:

pnpm check

안전 경계

서버는 POCKET_NOTES_FILE로 지정한 JSON 파일만 읽고 씁니다.
새 메모를 추가할 뿐 기존 메모를 삭제하지 않습니다.
저장 중 파일이 깨지지 않도록 임시 파일을 만든 뒤 교체합니다.
입력 폼에는 비밀번호나 API 키를 적지 마세요.
실제 승인과 권한 관리는 MCP Host가 담당합니다.

공식 자료

Available Tools

5 tools

analyze_notesAnalyze note tagsA

Read-onlyIdempotent

Count notes by tag while demonstrating MCP progress notifications and cancellation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`tags`	Yes
`noteCount`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool demonstrates 'MCP progress notifications and cancellation', which is a behavioral trait beyond what annotations provide. This gives the agent awareness of progress feedback and abort capability. No contradictions with annotations.

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

Conciseness4/5

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

The description is a single sentence, which is concise. However, it combines two distinct purposes: the core functionality and a demonstration of MCP features. Separating these would improve clarity. Nonetheless, it is efficiently short.

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 has no parameters and an output schema exists (reducing the burden), the description is minimal. It does not explain the scope (e.g., all notes or user's notes) or the output format. While the core action is clear, more context would help, such as mentioning that it aggregates across the entire workspace.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so schema coverage is 100% trivially. The description has no need to explain parameters. The baseline for zero-parameter tools is 4, and the description does not add or miss anything significant here.

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 core action: 'Count notes by tag', which is a specific verb+resource. It distinguishes from siblings like 'list_notes' and 'summarize_note' by implying aggregation. However, the secondary clause 'while demonstrating MCP progress notifications and cancellation' introduces a meta-purpose that could confuse an AI agent about the primary function.

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. For example, it does not compare to 'list_notes' or 'summarize_note' or state that this tool is best for getting a tag-based summary. The description only states what the tool does, which leaves the agent without decision-making context.

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

create_note_interactiveCreate note interactivelyA

Ask the user for non-sensitive note fields through MCP form elicitation, then create the note.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Description discloses interactive input and creation behavior. Annotations are neutral; no contradiction. Could mention data modification, but clear enough.

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 concise sentence front-loading key action and method, no wasted words.

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

Completeness5/5

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

Given zero parameters and no output schema, description fully captures tool's purpose and interaction pattern.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has no parameters; description explains why (user provides via form), adding value beyond schema.

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?

Description clearly states the verb 'Ask the user' and resource 'note', and differentiates from siblings by indicating interactive input via form elicitation.

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?

Description implies usage when needing interactive note creation without explicit when-not or alternatives, though sibling list provides context.

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

list_notesList notesA

Read-onlyIdempotent

List note summaries, optionally filtered by an exact tag.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No	Optional exact tag filter

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`notes`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive. Description is consistent but adds no extra behavioral context beyond what annotations provide.

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?

Extremely concise two-sentence description, front-loaded with verb and resource, no superfluous words.

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?

Adequate for a simple list tool with output schema and annotations; missing details like pagination or summary content but overall sufficient.

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%; description mirrors the schema without adding new meaning, meeting baseline for high coverage.

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?

Description clearly states the tool lists note summaries with optional tag filtering, distinguishing it from siblings like analyze_notes or create_note_interactive.

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; no explicit when-to-use or when-not-to-use conditions.

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

list_workspace_rootsList client workspace rootsA

Read-onlyIdempotent

Ask the MCP client which workspace roots it has made available to this server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds the useful context that the tool asks the MCP client, implying a remote interaction. No contradictions.

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

Conciseness5/5

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

The description is a single sentence with no wasted words, front-loaded with the key action and resource.

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 no output schema, the description should ideally hint at the return value (e.g., a list of root paths). It is adequate but could be more explicit about what is returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is trivially 100%. The description does not need to add parameter information, so a baseline score of 4 is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'ask' and the resource 'workspace roots', and it is clearly distinguished from siblings which operate on notes.

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 does not explicitly state when to use or not use this tool, nor does it provide alternatives, though the purpose is implicitly clear given the sibling tools.

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

summarize_noteSummarize note with the host modelA

Read-only

Read a note and ask the MCP client's language model to summarize it using MCP sampling.

ParametersJSON Schema

Name	Required	Description	Default
`noteId`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true, so no destructive behavior is expected. The description adds that the tool uses MCP sampling (client's language model), which is a key behavioral trait. However, it does not elaborate on potential side effects, latency, or requirements like model availability.

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, front-loaded sentence that conveys the essential purpose without superfluous words. It is appropriately concise.

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 simplicity (one required parameter, no output schema), the description covers the main action adequately. However, it omits details about the return format or what the agent receives after using sampling, leaving some incompleteness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the parameter. It only mentions 'noteId' without additional meaning or context (e.g., expected format, source, or how to obtain it). The description does not compensate for the missing schema documentation.

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

Purpose5/5

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

The description clearly states the specific action: read a note and summarize it using MCP sampling. It distinguishes from siblings like list_notes or create_note_interactive, which serve different purposes.

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 when to use (when summarization is needed) but provides no explicit conditions, exclusions, or comparisons with alternative tools. It lacks guidance on when not to use this tool.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing notes with optional tag filter, analyzing notes by tag, summarizing a note via sampling, interactively creating a note, and listing workspace roots. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., list_notes, analyze_notes, summarize_note, create_note_interactive, list_workspace_roots), making them predictable and easy to parse.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of demonstrating MCP features (progress notifications, sampling, form elicitation, workspace roots) while maintaining a manageable tool surface.

Completeness2/5

As a notes management server, essential operations like updating, deleting, or searching notes are missing. The tool set is incomplete for actual note management, likely because it prioritizes demonstrating MCP capabilities over full CRUD coverage.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

ctlsurf
com.ctlsurf
System-of-record notebook for AI coding agents: pages, datastores, tasks, skills over MCP.
Knowledge & Memory Developer Tools Autonomous Agents
2
smithery-ai-cookbook-ts-smithery-cli
ai.smithery
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
Developer Tools
213
Jade Note
app.jadenote
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Note Taking Knowledge & Memory
2
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

FastMCP Demo
Developer Tools
gogouravr
F
license
B
quality
D
maintenance
A demonstration TypeScript MCP server that showcases basic MCP concepts with simple tools (greeting, calculator), text resources, and prompt templates for learning the Model Context Protocol.
Updated 10 months ago (2025-11-16 11:28 UTC)
2
API MCP Server
Note Taking Text Summarization Developer Tools
vilasone455
F
license
B
quality
D
maintenance
A TypeScript-based MCP server that implements a simple notes system, providing resources for accessing notes via URIs, tools for creating notes, and prompts for generating summaries.
Updated 9 months ago (2025-11-25 08:38 UTC)
7
21
mcp-low-level-server
Note Taking Text Summarization Developer Tools
0GiS0
F
license
Not graded
quality
D
maintenance
A TypeScript-based MCP server that implements a simple note-taking system using low-level server components and streamable HTTP. It enables users to create, store, and summarize text notes through a set of tools, resources, and specialized prompts.
Updated a year ago (2025-06-30 10:39 UTC)
3
test-mcp
Developer Tools
rrjoson
A
license
Not graded
quality
D
maintenance
A minimal test MCP server built with TypeScript, demonstrating basic Model Context Protocol capabilities like tools, resources, and prompts.
Updated a year ago (2025-07-14 06:48 UTC)
24
ISC

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/fredisbusy/pocket-notes-mcp'

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