bear-notes-mcp
This server provides a local-first interface to Bear Notes on macOS, with read capabilities always available and write capabilities unlocked via an optional Edit Mode. All processing happens locally — no network calls or telemetry.
Read tools (always available):
Search notes: Relevance-ranked search across titles, body content, and OCR text from attachments; supports filtering by tag, date range (relative dates like "yesterday" or "last week"), and pinned status
Open a note: Read full content of a note by ID or title, including OCR'd text from images and PDFs
Find untagged notes: List all notes with no tags assigned
List tags: View all tags as a hierarchical tree with note counts
Check capabilities: Report current server mode and how to unlock additional features
Write tools (require Edit Mode opt-in):
Create notes: New notes with optional title, content, and tags
Add text: Insert text at the beginning, end, or a specific section (by header) of a note
Replace text: Replace the full body or a specific section of a note
Attach files: Attach images, PDFs, or documents (up to 25 MB) to a note, making content searchable via OCR
Add tags: Add one or more tags to an existing note
Archive notes: Archive a note without deleting it
Rename tags: Rename a tag across the entire library
Delete tags: Remove a tag from all notes without deleting the notes themselves
Reads go directly to Bear's SQLite database (Bear doesn't need to be open); writes route through Bear's URL handler for safe, validated operations.
Bear Notes MCP Server
An unofficial, opinionated MCP server for Bear Notes — built around relevance-ranked search instead of substring matching. Results come ranked across titles, bodies, and hierarchical tags, with snippets and combinable filters (tag, date, pinned). Reads run direct against Bear's SQLite database — no Bear app required for queries.
Writes route through Bear's own URL handler — atomic and validated by Bear. Offline-first: no network calls, no telemetry, all processing on your Mac. Works with any MCP client — Claude Desktop, Claude Code, Codex, Gemini, Cursor. Ships as a one-click .mcpb extension or a standalone npm package.
Example prompts:
Find the deep-dive I wrote on export pipelines, somewhere under #engineering/
Append today's decisions to the 'Decisions' section of my Weekly Ops note
Pull every note under #research/llm-evals into a survey outline
Find my notes tagged #blog/drafts and draft this week's post outline

✨ Key Features
Read-only by default — flip Edit Mode for writes. 4 tools always on (search, open, find untagged, list tags); 8 more in Edit Mode for create, edit, attach, tag, archive
Relevance-ranked search across titles, bodies, and tags — finds the right note, not just the ones that contained your literal words
Date-based search with relative dates ("yesterday", "last week", "start of last month")
Hierarchical tag management — view tags as a tree with note counts; rename or delete a tag across the whole library
Surgical writes — append at a specific heading or replace a section without rewriting the whole note
File attachments — attach images, PDFs, and documents up to 25 MB; symlinks rejected for safety
New note convention (opt-in) — place tags right after the title instead of at the bottom
Local-first — direct read-only SQLite reads, native
node:sqlite, no network calls, no telemetry
Complete privacy (except the data you send to your AI provider when using an AI assistant, of course): this server makes no external connections. All processing happens locally on your Mac using Bear's own database and API. There is no extra telemetry, usage statistics or anything like that.
Related MCP server: Bear MCP Server
👤 Who is this for
This is an unofficial, opinionated alternative to the native Bear MCP. It fits when:
You have years of notes and substring search isn't enough. Search ranks results by relevance — titles, bodies, and tag matches across the whole library — so the right note rises to the top, even when your phrasing has drifted.
You bounce between MCP clients. Stdio transport works with Claude Desktop, Claude Code, Codex CLI, Gemini, Cursor, Windsurf — anything that speaks MCP. No per-client glue code, no lock-in.
You want to query without pulling Bear forward. Reads run straight against Bear's SQLite database. No need to keep Bear open — or even running — for a quick lookup mid-conversation. (Writes still route through Bear, atomically.)
You manage tags across the whole library. Rename or delete a tag everywhere it appears, atomically. Hierarchical tag matching in search rolls up subtags automatically — work that's tedious through Bear's UI alone.
You care about supply-chain hygiene. Native
node:sqlite— no unsigned third-party binaries, no Gatekeeper hassles. Network-free server: no remote-fetch tools, no prompt-injection surface.
If you have a small library and just want a quick notes integration, you may not need this yet.
📦 Installation
Claude Desktop Extension
Prerequisites: Bear app must be installed and Claude Desktop must be installed.
Download the latest
bear-notes-mcpb-*.mcpbextension file from ReleasesMake sure your Claude Desktop is running (start if not)
Doubleclick on the extension file – Claude Desktop should show you the installation prompt
If doubleclick does not work for some reason, then open Claude -> Settings -> Extensions -> Advanced Settings -> click "Install Extension".
DONE!
Ask Claude to search your Bear notes with a query like "Search my Bear notes for 'meeting'" - you should see your notes appear in the response!
Standalone MCP Server
Want to use this Bear Notes MCP server with Claude Code, Cursor, Codex, or other AI assistants?
Requirements: Node.js 24.13.0+
Claude Code (one command)
claude mcp add -s user bear-notes -- npx -y bear-notes-mcp@latestOther AI Assistants
Add to your MCP configuration file:
{
"mcpServers": {
"bear-notes": {
"command": "npx",
"args": ["-y", "bear-notes-mcp@latest"]
}
}
}More installation options and local development setup — NPM.md
🛠️ Tools
bear-open-note- Read the full text content of a Bear note by its ID or title, including OCR'd text from attached images and PDFsbear-create-note- Create a new note in your Bear library with optional title, content, and tagsbear-search-notes- Find notes by relevance across titles, body, and OCR-extracted text from attached images and PDFs. Use a phrase or a few keywords describing what you're looking for; results are ranked by relevance and each includes a context snippet. Also supports tag, date-range, and pinned-only filters — combine with a search term or use them on their own to browse.bear-add-text- Insert text at the beginning or end of a Bear note, or within a specific section identified by its header. Requires the note's current revision token (theRevision: Nline from your last response that referenced it); writes against a stale revision are rejected with an instruction to re-read with bear-open-note before retrying.bear-replace-text- Replace content in an existing Bear note — either the full body or a specific section. Requires the note's current revision token (theRevision: Nline from your last response that referenced it); writes against a stale revision are rejected with an instruction to re-read with bear-open-note before retrying.bear-add-file- Attach a local file (image, PDF, document) to an existing Bear note by its ID or title. Bear extracts text from images and PDFs via OCR, making attachment content searchable. Requires the note's current revision token (theRevision: Nline from your last response that referenced it); writes against a stale revision are rejected with an instruction to re-read with bear-open-note before retrying.bear-list-tags- List all tags in your Bear library as a hierarchical tree with note countsbear-find-untagged-notes- Find notes in your Bear library that have no tags assignedbear-add-tag- Add one or more tags to an existing Bear note. Requires the note's current revision token (theRevision: Nline from your last response that referenced it); writes against a stale revision are rejected with an instruction to re-read with bear-open-note before retrying.bear-archive-note- Archive a Bear note to remove it from active lists without deleting itbear-rename-tag- Rename a tag across all notes in your Bear librarybear-delete-tag- Delete a tag from all notes in your Bear library without affecting the notesbear-capabilities- Report the current server mode (read-only or Edit Mode) and how to unlock additional capabilities
⚙️ Configuration
Debug Logging
Enable verbose logging for troubleshooting.
Claude Desktop: Settings → Extensions → Configure (next to Bear Notes) → toggle "Debug Logging" → Save → Restart Claude
Standalone MCP server: set environment variable
UI_DEBUG_TOGGLE=true
New Note Convention
By default, Bear places tags at the bottom of a note when created via API. Enable this option to place tags right after the title instead, separated by a horizontal rule.
┌──────────────────────────────┐
│ # Meeting Notes │ ← Note title
│ #work #meetings │ ← Tags right after title
│ │
│ --- │ ← Separator
│ │
│ Lorem Ipsum... │ ← Note body
└──────────────────────────────┘This convention isdisabled by default — it's opt-in so existing behavior is preserved.
Claude Desktop: Settings → Extensions → Configure (next to Bear Notes) → toggle "New Note Convention" → Save → Restart Claude
Standalone MCP server: set environment variable
UI_ENABLE_NEW_NOTE_CONVENTION=true
Example standalone configuration with the convention enabled:
{
"mcpServers": {
"bear-notes": {
"command": "npx",
"args": ["-y", "bear-notes-mcp@latest"],
"env": {
"UI_ENABLE_NEW_NOTE_CONVENTION": "true"
}
}
}
}Edit Mode
Edit Mode unlocks all 8 write tools: create notes, add or replace text (full body or by section header), attach files, manage tags, archive. When off, the server is fully read-only — tools/list returns the 4 read tools (bear-open-note, bear-search-notes, bear-find-untagged-notes, bear-list-tags) plus bear-capabilities (a discovery tool that surfaces this unlock guidance for clients that drop the MCP instructions field). The LLM cannot mutate your library by mistake.
Edit Mode isoff by default so the server is provably read-only out of the box. Turn it on when you're ready for writes — and only when.
Claude Desktop: Settings → Extensions → Configure (next to Bear Notes) → toggle "Edit Mode" → Save → Restart Claude
Standalone MCP server: set environment variable
UI_ENABLE_CONTENT_REPLACEMENT=true
Example standalone configuration with Edit Mode enabled:
{
"mcpServers": {
"bear-notes": {
"command": "npx",
"args": ["-y", "bear-notes-mcp@latest"],
"env": {
"UI_ENABLE_CONTENT_REPLACEMENT": "true"
}
}
}
}Technical Details
This server reads your Bear Notes SQLite database directly for search/read operations and uses Bear's X-callback-URL API for write operations. All data processing happens locally on your machine with no external network calls.
Platforms Supported
macOS only because Bear desktop works only on macOS.
Logs
Claude Desktop:
MCP server logs go into
~/Library/Logs/Claude/main.log, look forbear-notes-mcpMCP transport logs go to
~/Library/Logs/Claude/mcp-server-Bear\ Notes.log
Standalone MCP server:
Logs are written to stderr; enable debug logging with
UI_DEBUG_TOGGLE=true
FAQ
Could this steal my data?
No. The server only reads Bear's local database (same data Bear app shows you) and uses Bear's native API to add text to the notes. No network transmission, no external servers.
Why SQLite and not just a native Bear app's x-callback-url API?
For read operations (search/open), the x-callback-url API returns the note data in x-success response: that would require a server or custom binary to handle x-success responses - both risky and fragile. Direct SQLite read-only access is simpler and more reliable for searching and reading notes.
Why native Node.js SQLite instead of third-party packages?
This avoids shipping an SQLite binary from third-party node packages, which poses supply chain risks and blocks the Claude Desktop extension from running on macOS.
Anthropic does not sign third-party SQLite binaries (obviously), causing macOS security systems to flag that the Claude process from a binary signed by Anthropic is trying to run another binary signed by a third party. As a result, Claude Desktop cannot run the extension.
When I install the extension, I see a red warning: "Installing will grant access to everything on your computer." - what does this mean?
This is how Claude for Desktop reacts to the fact that this extension needs access to the Bear SQLite database on your Mac.
Claude warning system does not distinguish between the need to access only one file (what the extension does) versus the need to access all files (this is NOT what the extension does).
One of the ways to validate this is asking your Claude to analyze the codebase (it is pretty small) before installing the extension and tell you.
How can I report a bug or contribute?
Use issues or discussions! I'd be glad to see your feedback or suggestions, or your help to make this project better! ❤️
Staying Up To Date
Consider subscribing to release announcements to know when a new version is released:

I also post to reddit.com/r/bearapp/ when there's a new release.
Available Tools
5 toolsbear-capabilitiesBear Notes CapabilitiesARead-onlyIdempotent
Report the current Bear Notes MCP server mode and how to unlock additional capabilities. Call this when the user asks what you can do with their Bear notes, when a write operation appears unavailable, or when the user wants to enable note creation, editing, or tag management.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and idempotentHint=true. Description adds context that the tool reports current mode and unlock instructions, which goes beyond annotations. It does not contradict annotations and clarifies the tool is informational.
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?
Description is two sentences with no filler. It is front-loaded with the core action and then adds usage guidance. Every sentence 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?
Given no parameters, no output schema, and a simple task, the description is sufficient. It explains the tool's purpose and when to use it. Could mention what specifically 'reporting mode' outputs, but it is 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?
Tool has no parameters, so the schema coverage is effectively 100%. Description adds no parameter info, but with zero parameters this is not needed. The baseline for 0 parameters is 4, and the description meets 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 explicitly states the tool reports the current mood and how to unlock additional capabilities. Verb 'Report' and resource 'Bear Notes MCP server mode' are specific and distinct from sibling tools like bear-search-notes or bear-list-tags.
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?
Description provides explicit scenarios for when to call: when user asks what can be done with Bear notes, when write operations seem unavailable, or when user wants to enable note creation/editing/tag management. This clarity helps the agent choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bear-find-untagged-notesFind Untagged NotesARead-onlyIdempotent
Find notes in your Bear library that have no tags. Useful for organizing and categorizing notes. Trashed and archived notes are not included.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default: 50, min: 1) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds valuable context by stating that trashed and archived notes are excluded, which is beyond the annotations. No contradictions and the added behavioral detail is clear.
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, consisting of three short sentences. The first sentence immediately communicates the action, the second adds context, and the third provides an important scope exclusion. No superfluous information.
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 covers the tool's purpose, use case, and exclusion of trashed/archived notes. It does not mention return format or the limit parameter, but given the tool's simplicity and the schema covering limit, it is mostly complete. A minor gap is the lack of output format hints.
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?
With 100% schema coverage for the single parameter 'limit', the schema already documents its type, range, and default. The description does not add any additional semantic meaning for the parameter, so 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 tool finds notes without tags in Bear library, explicitly excluding trashed and archived notes. It distinguishes itself from sibling tools like bear-search-notes by focusing on untagged notes, providing a specific verb-resource-scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'useful for organizing and categorizing notes' but does not provide explicit guidance on when to use this tool versus alternatives like bear-search-notes or bear-list-tags. No when-not-to-use or direct comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bear-list-tagsList Bear TagsARead-onlyIdempotent
List all tags in your Bear library as a hierarchical tree. Shows tag names with note counts. Useful for understanding your tag structure and finding tags to apply to untagged notes. Counts include only active notes (trashed and archived are excluded). Tags with zero active notes are not shown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral details beyond annotations: counts exclude trashed/archived notes and tags with zero active notes. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are well-structured and front-loaded. Each sentence provides essential information without redundancy or unnecessary detail.
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 zero-parameter read-only tool with good annotations, the description is complete. It explains the output format, what's included/excluded, and the tool's utility.
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?
With zero parameters, the schema coverage is 100%. The description adds value by explaining what the output contains (hierarchical tree, note counts), which is helpful given no output schema.
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 lists all tags as a hierarchical tree with note counts, and explicitly excludes trashed/archived notes and tags with zero active notes. This is a specific verb+resource that distinguishes it from siblings like bear-find-untagged-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 says it is useful for understanding tag structure and finding tags for untagged notes, implying when to use it. However, it does not explicitly state when not to use it or mention alternatives, though siblings provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bear-open-noteOpen Bear NoteARead-onlyIdempotent
Read the full text content of a Bear note by its ID or title. Supports direct title lookup as an alternative to searching first. Always includes text extracted from attached images and PDFs (aka OCR search) with clear labeling.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Note identifier (ID) for an existing Bear note. Either id or title must be provided. | |
| title | No | Exact note title for direct lookup (case-insensitive). Either id or title must be provided. If multiple notes share the same title, returns a list for disambiguation. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, idempotentHint=true), description discloses that OCR text from images/PDFs is included and clearly labeled. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Front-loaded with main action. Every sentence 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 two parameters and no output schema, the description covers purpose, parameter usage, and important behavioral detail (OCR inclusion). 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 has 100% coverage, and description adds extra meaning: title is case-insensitive, and if multiple notes share the same title, returns a list for disambiguation. This is valuable beyond the schema.
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?
Clearly states it reads full text content of a Bear note by ID or title. Explicitly mentions direct title lookup as alternative to searching, and includes OCR text from images/PDFs. Distinguishes from sibling tools like bear-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?
Provides guidance on when to use direct title lookup versus searching first. Does not explicitly exclude use cases or mention siblings for comparison, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bear-search-notesFind Bear NotesARead-onlyIdempotent
Search your Bear notes for words or phrases. The search looks across note titles, body content, and OCR text in attached images and PDFs, returning matching notes ranked by relevance with a snippet of the matching context — so you can see what matched without opening the note. For best results, search with a phrase or several words from what you're looking for; a single word also works. Also supports filtering by tag, by creation/modification date range, or by pinned status — combine these with a search term, or use them on their own to browse without searching. Trashed and archived notes are not included.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Tag to filter notes by (leading # is stripped if present) | |
| term | No | Words to search for. Results are ranked by relevance — notes covering more of what you typed rank higher. Pass natural keywords for the typical case (e.g., "quarterly planning notes"). Hyphenated or punctuated identifiers like "bear-notes-mcp" or "2026-04-15" are matched as a phrase when used alone; in multi-word queries they are treated like any other word. | |
| limit | No | Maximum number of results to return (default: 30, min: 1) | |
| pinned | No | Set to true to return only pinned notes: if combined with tag, will return pinned notes with that tag, otherwise only globally pinned notes. | |
| createdAfter | No | Filter notes created on or after this date. Supports: relative dates ("today", "yesterday", "last week", "start of last month"), ISO format (YYYY-MM-DD). Use "start of last month" for the beginning of the previous month. | |
| createdBefore | No | Filter notes created on or before this date. Supports: relative dates ("today", "yesterday", "last week", "end of last month"), ISO format (YYYY-MM-DD). Use "end of last month" for the end of the previous month. | |
| modifiedAfter | No | Filter notes modified on or after this date. Supports: relative dates ("today", "yesterday", "last week", "start of last month"), ISO format (YYYY-MM-DD). Use "start of last month" for the beginning of the previous month. | |
| modifiedBefore | No | Filter notes modified on or before this date. Supports: relative dates ("today", "yesterday", "last week", "end of last month"), ISO format (YYYY-MM-DD). Use "end of last month" for the end of the previous month. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent behavior. Description adds context: notes are ranked by relevance, returns snippets, and excludes trashed/archived notes. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured in a logical flow: purpose, return format, usage tips, then filter details. Front-loaded with the core function. All sentences add value, though slightly verbose for a summary.
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 8 optional parameters and no output schema, the description thoroughly covers search scope, result format, filter options, and exclusions (trashed/archived). Provides sufficient context for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description adds extra context: explains term matching with hyphenated identifiers, that tag strips leading #, and relative date formats. That adds value beyond the schema.
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 Bear notes for words or phrases, covering titles, body, and OCR content. It distinguishes itself from siblings (e.g., bear-list-tags, bear-open-note) by focusing on search and 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?
Provides explicit guidance on best practices (phrase or several words for best results) and explains how to combine filters or use them independently. Notes that trashed/archived notes are excluded, but does not explicitly mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
12 tool updates
v3.0.1- Removed
bear-add-file - Removed
bear-add-tag - Removed
bear-add-text - Removed
bear-archive-note - Added
bear-capabilities - Removed
bear-create-note - Removed
bear-delete-tag - Changed
bear-find-untagged-notes4 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results (default: 50)"New value: +"Maximum number of results (default: 50, min: 1)" - added
Input schema / properties / limit / maximumAdded value: +9007199254740991 - added
Input schema / properties / limit / minimumAdded value: +1 - changed
Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"
- Changed
bear-open-note1 field changed- changed
Input schema / properties / id / descriptionPrevious value: -"Note identifier (ID) from bear-search-notes. Either id or title must be provided."New value: +"Note identifier (ID) for an existing Bear note. Either id or title must be provided."
- Removed
bear-rename-tag - Removed
bear-replace-text - Changed
bear-search-notes6 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (default: 50)"New value: +"Maximum number of results to return (default: 30, min: 1)" - added
Input schema / properties / limit / maximumAdded value: +9007199254740991 - added
Input schema / properties / limit / minimumAdded value: +1 - changed
Input schema / properties / limit / typePrevious value: -"number"New value: +"integer" - changed
Input schema / properties / tag / descriptionPrevious value: -"Tag to filter notes by (without # symbol)"New value: +"Tag to filter notes by (leading # is stripped if present)" - changed
Input schema / properties / term / descriptionPrevious value: -"Text to search for in note titles and content"New value: +"Words to search for. Results are ranked by relevance — notes covering more of what you typed rank higher. Pass natural keywords for the typical case (e.g., \"quarterly planning notes\"). Hyphenated or punctuated identifiers like \"bear-notes-mcp\" or \"2026-04-15\" are matched as a phrase when used alone; in multi-word queries they are treated like any other word."
TDQS
Each tool has a clearly distinct purpose: capabilities for mode info, find-untagged-notes for organizing, list-tags for hierarchy, open-note for reading, search-notes for searching. No overlap.
All tools follow a consistent 'bear-verb-noun' pattern (bear-capabilities, bear-find-untagged-notes, bear-list-tags, bear-open-note, bear-search-notes). Camel-case and hyphens are used uniformly.
5 tools is well-scoped for a note-taking assistant. Covers core read and organization tasks without being excessive or thin.
The server lacks create, update, and delete operations for notes and tags. It is read-only and search-focused, with no ability to modify notes or manage tags beyond listing. Significant gaps for a full note-management tool.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- TaprootOAuthcom.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAllows the AI to read from your Bear Notes3245MIT
- AlicenseAqualityCmaintenanceAn MCP server that integrates Bear Note Taking App with Claude Desktop, allowing Claude to read, create, search notes and manage tags directly from Bear.71MIT
- FlicenseBqualityDmaintenanceA Model Context Protocol server that provides Claude with access to search, retrieve, and analyze notes from the Bear App through natural language queries.78-
- AlicenseAqualityDmaintenanceA Python-based MCP server that provides read and write access to Bear Notes on macOS using SQLite for data retrieval and x-callback-url for modifications. It enables users to search, create, archive, and manage notes and tags directly through a Model Context Protocol interface.161ISC
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/vasylenko/bear-notes-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server